On 2012-10-10 17:56, Walter Bright wrote:

> Exactly. Embedding it in a comment section accomplishes exactly nothing
> if the linker ignores it.

DMD calls the linker (or rather GCC). Just read the section and append a link flag. But that might turn DMD into a linker.

Again, I think all this should be handled by a build tool and a package manager.

-- 
/Jacob Carlborg

On Wednesday, 10 October 2012 at 19:19:12 UTC, Jacob Carlborg wrote:
> If I recall correctly, using pragma(lib) with dmd, you need to specify the extension for the library, ending up with code like this:

Nope, the extension is optional. I never use it.


pragma(lib, "pq");

On Wed, Oct 10, 2012 at 10:56:30PM +0400, Dmitry Olshansky wrote:
> On 10-Oct-12 22:54, H. S. Teoh wrote:
> >On Wed, Oct 10, 2012 at 08:56:49AM -0700, Walter Bright wrote:
> >>On 10/10/2012 8:19 AM, Simen Kjaeraas wrote:
> >>>On 2012-10-10, 16:19, Walter Bright wrote:
> >>>>Some object module formats do not have the ability to embed a
> >>>>library reference in them. Elf (cough cough), Mach-O (wheeze)
> >>>
> >>>ELF has .comment and .note sections. While they're not exactly intended for the purpose, they seem to fit the bill?
> >>>
> >>>It'd of course require a linker to know what to do with the data, but it seems to me this would not interfere with other uses.
> >>
> >>Exactly. Embedding it in a comment section accomplishes exactly nothing if the linker ignores it.
> >[...]
> >
> >I thought the point was that linkers that *did* understand it will do the right thing, and linkers that don't will fall back to the traditional way (require specifying libraries on the command-line).
> >
> 
> BTW making the smart linker driver should be relatively easy: just get the special section contents out of passed object files and turn that into a full blown set of flags for a dumb linker.
[...]

Excellent idea!


T

-- 
Guns don't kill people. Bullets do.

On 10/10/2012 11:56 AM, Dmitry Olshansky wrote:
> BTW making the smart linker driver should be relatively easy: just get the
> special section contents out of passed object files and turn that into a full
> blown set of flags for a dumb linker.

Not that easy. You'd have to do it also with the objects pulled in from library files. Essentially, you have to implement most of the linker to do that.

Not worth it.

On Wednesday, 10 October 2012 at 19:21:58 UTC, Jacob Carlborg wrote:
> On 2012-10-10 17:00, Jesse Phillips wrote:
>> As for versions. I don't know what version of ole32.dll I'm using or how
>> to find out, I don't really care either. But I guess it would be good to
>> have the option though.
>
> A package manager would be the solution for that.

I don't see why, I'm the programmer I'd have to tell the package manager what version I'm using... and again I don't know what it is. I'd think pragma(lib) + package manager would get along nicely.

"Hi there, I need this library." says the source file.

"Hmm, ok, let me get this version as I've been instructed to do so." replies the PM.

"Hey, what about me... lib..." says a close friend.

"Yeah, yeah, let me see... how does the latest version sound/what is installed? I don't know what you need but we can give this a try." sadly replies the PM.

"Mister programmer man, you have unspecified library versions for... What do would you like to do with them? Did the currently selected version work out for you?" The PM tells the programmer.

On 2012-10-11 04:54, Jesse Phillips wrote:

> I don't see why, I'm the programmer I'd have to tell the package manager
> what version I'm using... and again I don't know what it is. I'd think
> pragma(lib) + package manager would get along nicely.

You don't know what version of a library you're using? That sounds pretty bad. Sure you might not need to know which version of a system library you're using but you should really know the version of all third party libraries you're using. Otherwise there's a huge risk of things starting to break.

What about any other compile or link flags, do you keep them in a separate file? Why would you keep half of the flags in one file and the other half in another file?

> "Hi there, I need this library." says the source file.
>
> "Hmm, ok, let me get this version as I've been instructed to do so."
> replies the PM.
>
> "Hey, what about me... lib..." says a close friend.
>
> "Yeah, yeah, let me see... how does the latest version sound/what is
> installed? I don't know what you need but we can give this a try." sadly
> replies the PM.

So it just picks a random version, that doesn't sound like very good behavior.

> "Mister programmer man, you have unspecified library versions for...
> What do would you like to do with them? Did the currently selected
> version work out for you?" The PM tells the programmer.

So this is just a guessing game, trail and error?

I think it would be much better to work with packages and not individual libraries. You would just tell the build tool, compiler or whatever to use package "foo". Then the package manager figures out what libraries and dependencies it needs to link to and also the path to the import files.

-- 
/Jacob Carlborg

On 2012-10-11 04:54, Jesse Phillips wrote:
> On Wednesday, 10 October 2012 at 19:21:58 UTC, Jacob Carlborg wrote:
>> On 2012-10-10 17:00, Jesse Phillips wrote:
>>> As for versions. I don't know what version of ole32.dll I'm using or how
>>> to find out, I don't really care either. But I guess it would be good to
>>> have the option though.
>>
>> A package manager would be the solution for that.
>
> I don't see why, I'm the programmer I'd have to tell the package manager
> what version I'm using... and again I don't know what it is. I'd think
> pragma(lib) + package manager would get along nicely.
>
> "Hi there, I need this library." says the source file.
>
> "Hmm, ok, let me get this version as I've been instructed to do so."
> replies the PM.
>
> "Hey, what about me... lib..." says a close friend.
>
> "Yeah, yeah, let me see... how does the latest version sound/what is
> installed? I don't know what you need but we can give this a try." sadly
> replies the PM.
>
> "Mister programmer man, you have unspecified library versions for...
> What do would you like to do with them? Did the currently selected
> version work out for you?" The PM tells the programmer.

Also see my other post:

http://forum.dlang.org/thread/mailman.695.1349857389.5162.digitalmars-d@puremagic.com?page=3#post-k54hng:241rra:241:40digitalmars.com

-- 
/Jacob Carlborg

On 2012-10-11 01:18, Walter Bright wrote:

> Not that easy. You'd have to do it also with the objects pulled in from
> library files. Essentially, you have to implement most of the linker to
> do that.
>
> Not worth it.

Maybe it's time to update the old tool chain that we inherited form the 70s, but this is a totally different discussion.

-- 
/Jacob Carlborg

On Wed, 10 Oct 2012 16:32:05 +0200, Paulo Pinto <pjmlp@progtools.org> wrote:

> On Wednesday, 10 October 2012 at 14:44:20 UTC, Walter Bright wrote:
>> On 10/10/2012 4:49 AM, Paulo Pinto wrote:
>>> On Wednesday, 10 October 2012 at 11:50:29 UTC, Manu wrote:
>>>> Really? Is it an MS thing? I'm amazed the other compilers haven't adopted
>>>> that in the last 10 years or whatever.
>>>
>>> Yes, it is a Microsoft extension. I never saw it in any other C or C++ compiler.
>>
>> Digital Mars C and C++ !!
>
> I only became aware of Digital Mars thanks to D, I must confess.
>
> When I moved away from Turbo Pascal, I started using Turbo C and Turbo C++, followed by Borland C++ and eventually Visual C++.
>
> Then at the university I started to use vendor's C and C++ compilers of the multiple UNIX systems we had access to.
>
> I used to see adverts for Watcom C/C++, High C/C++ and Zortech C/C++ in computer magazines, but never knew anyone that had access to them.
>

You really missed something. For years Zortech/Sysmantec/DigitalMars C++ has been my preferred compiler. Generated fast code very fast! With being STLport'ed it also had decent support for STL. It often times barked about issues with Type checking other compilers did not even mention. Which saved me from quite a few bugs.
When porting big C++ libraries like wxWidgets (then wxWindows) it became apparent to me DMC++ did need the least special treatment to make it compile the code. Also ported various Boost libs to it.
It wasn't util VS2005 came along before I started shifting away...

About Watcom? Well a complete opposite experience...

Arjan

On 10 October 2012 21:55, Jacob Carlborg <doob@me.com> wrote:

> On 2012-10-10 14:59, Manu wrote:
>
>  None of those things actually embody the information about the
>> relationship, nor can they. The source code does, and nothing else.
>> Features that imply the dependency may (and often are) be disabled at
>> compile time.
>> I rather like that the compiler is able to put a note in the object file
>> that it depends on a particular lib, because it does.
>> I'm not sure how a package manager helps... What is a package manager? ;)
>> I'd like to hear some reasons why that is a bad or undesirable thing, or
>> is this just an opinion?
>>
>
> A package manager is a tool that downloads and installs libraries, application and tools, also known as packages. It also tracks and installs all the dependencies of a package automatically. RubyGems, CPAN, PEAR, npm are a couple of examples of package managers specifically made for a programming language.
>

Sorry, I do know what a package manager is. I was being facetious, in that
windows has no such concept, and most people use windows.
It's not practical to depend on anything like that.


This is my vision (simplified) of how build tool, package manager and the
> compiler work together.
>
> # build script
> package foo
> package bar
>
> files myapp/main.d
>
> $ build myapp
>
> The build tool "build" will read the build script and see that it has two dependencies: "foo" and "bar". The build tool will get information from the package manager about these packages. Information like the path to the import files/source/headers and the path to the library to link with.
>

I've never seen the 'custom build tool' option in Visual Studio (and if
there were one, certainly people don't use it). And no associated package
manager that automatically fetches dependencies...
Additionally, you're insisting build tool 'X' upon people, and I presume
it's not an established 'standard' build tool that's accepted/agreed on all
platforms. You'll never convince people to use it, and certainly not in in
proprietary situations where your tools are dictated.


The build tool will then simply invoke the compiler with the correct flags
> to be able to build and link with these libraries. The build tool will, of course, know the platform it runs on so it can call the compiler with different flags depending on the platform. On Posix it would probably link to "libfoo.a" where on Windows it would link to "foo.lib".
>
> If I recall correctly, using pragma(lib) with dmd, you need to specify the extension for the library, ending up with code like this:
>
> version (Posix)
>     pragma(lib, "foo.lib");
>
> else version (Windows)
>     pragma(lib, "libfoo.a");
>
> Which is just ridiculous. Sure you could change DMD to support for this. But what happens with dynamic libraries? .dll on Windows, .so on Linux/BSD and .dylib on Mac OS X. Then on Mac OS X there are various other types of dynamic libraries, like frameworks and bundles, with their own extension.
>

This is indeed ridiculous, but trivial. I'm sure it can be fixed in minutes. I don't think the solution is complicated, given a lib name, on linux it first looks for a lib*.so, then for a .a. Windows uses import libs, which will be resolved exactly the same as a static lib, and I don't know anything about OSX, is it not similar/same as linux?


Another point is that I don't want to separate the build script. Compile
> and link flags in one file and then the libraries to link with in a different file? That's just stupid.
>

What's a flag? you mean those little options in the property grid when you
Right Click->Properties on the project? ;)
People don't like doing that, and they really hate micro-managing a massive
list of libraries in there. Also those flags aren't configurable, you can't
just add one for your new feature of interest.

I also maintain that it's not stupid. The build script doesn't know what libs the code will link to. I guess you're arguing that your build-script should exclusively define the features/libs, not the other way around? This is annoying in a cross-platform environment, because all platforms tend to link a totally different set of libraries, and that means your build script is cluttered with annoying manually maintained lists for each platform, and the less commonly used/built platform ALWAYS seems to fall out of date.

In D's context, D has very powerful (and more manageable) static logic, I can see it being even more useful to have code-driven selection of dependencies in D than it already is in C.


With the approach with the build tool and the package manager working
> together the build tool can also automatically specify the path to the import files. How would you do that in a source file? Either the compiler would always need to read a special file first. Or it would need to scan all files for a particular pragma to get the import paths. Then it would rescan the files again during the actual compilation.
>

The linker would just need to be smart enough to gather the deps from the
objects while linking.
I've said before, my question is: is it _possible_ to do it in a cross
platform way currently? I see some other comments with ideas, maybe it is?


This is a specification/description of a package manager I'm working on:
>
> https://github.com/jacob-**carlborg/orbit/wiki/Orbit-** Package-Manager-for-D<https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D>


Does it work in windows and integrate with Visual Studio? If not, sadly, it's irrelevant.

But aside from that, I am curious, what makes it better/more useful than apt?