#pragma comment (lib, ...)

[Jacob Carlborg]

On 2012-10-12 23:43, Jesse Phillips wrote:

> Why can't I just tell the compile that I need library "foo," and the
> package manager can handle finding the package which provides that library?

Because package "foo" can contain several libraries. You also don't want 
to bother with the libraries "foo" depends on.

Say you have a project where you want to use Derelict. I much rather 
just say:

package derelict

Then some thing like this:

library libDerelictGL.a
library libDerelictUtil.a

> Packages depend on other packages, code depends on other code. I don't
> think it makes sense for code to depend on a package. Granted, packages
> could provide code that is depended on...

I don't understand why.

> On the note about flags... Most of them are external to the code, you
> could say they are the options of the package. However, for libraries,
> we have a separate program which can operate without the source code,
> thus the historical reason code dependencies are not stated in the code.
> Why should we have 'import?' Can't we just tell the compiler the files
> it will need for its symbols separately, I don't know... maybe we could
> add a flag to specify them so it would feel strange to have them in the
> source code too. (Sorry couldn't pass it up)

If you specify the path where the compiler should find import files in a 
source file, how should the compiler handle that?

* Have a special file that the compiler always reads first?

How is that any better than a build script?

* The compiler scans all files after these commands, add the import 
paths and then rescans the files?

This sounds very inefficient.

> As for the version number, you are right, I should know. But much of the
> code I write/use doesn't make release. This is where a handy and easy to
> use package manager comes in. Releases become simpler, there can be
> verified and tested versions of the depended libraries. But even with a
> tested version, that doesn't mean it will fail with older or newer
> versions of the package.

No, it does not.

> Linux creates symbolic links to its shared libraries to provide an
> unversioned link. And while all the packages know which version that is,
> third part applications do not. Yes, this arbitrary guessing game has
> its problems, but so does the strict version requirements. I've had to
> create symbolic links to a newer library to pretend I had an older
> version (as digging up such a version becomes hard when the package
> manager becomes worthless).

I think it's bad practice to depend on a library which you don't know 
the exact version.

But if you want, you don't need strict version requirements. RubyGems 
has this nice little feature of specifying versions:

gem "rails", "3.2.8" # specify exact version
gem "rails" # don't specify a version at all == latest version
gem "rails", "> 3.2.8" # any version newer than "3.2.8"

In these cases the digits in the version are interpreted as follows:

3 - Major
2 - Minor
8 - Build

Now, here's the interesting part:

gem "rails", "~> 3.2.8" # any version equal to 3.2.8 or a later build 
version

That is, "3.2.8" is ok, "3.2.15" is ok but "3.3.0" is not ok.

gem "rails", "~> 3.2" # any version equal to 3.2.0 or a later minor version

That is, "3.2.0" is ok, "3.2.8" is ok, "3.3.0" is ok but "4.0.0" is not ok.

> Anyway, I look forward to a good packaging system for D. But stating the
> dependency in that doing the depending does make sense. However I've
> realized that the dependency on a library only makes sense for header
> files, and header files only make sense when interfacing with C.
> Dependency on D code and libraries all come stated from the 'import'
> statement.

Ok, I really don't understand this last section.

-- 
/Jacob Carlborg