#pragma comment (lib, ...)

[Jacob Carlborg]

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.

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.

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.

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.

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.

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

-- 
/Jacob Carlborg