#pragma comment (lib, ...)

[Jacob Carlborg]

On 2012-10-11 13:22, Manu wrote:

> Okay, so I'll stop being a dick for a minute, I'm actually curious to
> know how you imagine it working with a tool like VisualStudio.
> It sounds like you're not just talking about a tool to fetch libs and
> dependencies, but also perform the build? And the dependencies are
> detailed in the build script?
> An inflexible build system like Visual Studio doesn't really handle that
> very well.

I'm talking about three separate tools that work close together. The 
package manager, the build tool and the compiler. The package manager 
handles packages, i.e. collection of files. The build tool tells the 
compiler what files to build, what compile and link flags to use. The 
build tool asks the package manager of any external dependencies.

If it would be possible to interact with the package manager directly 
from the compiler or source code, i.e. pragma(package) that would be 
fine. But it's always a bigger step to modify the compiler than creating 
a separate tool. I also don't really think that the compiler should 
handle this.

The compiler works with single files, the package manager works with 
collection of files, that is, packages.

> A package manager which collects libs and their dependencies into common
> include/lib paths sounds extremely useful. But to me it sounds even more
> useful when combined with #pragma lib! That conveniently eliminates the
> lib path issue.

I don't think that pragma(lib) works that way. It doesn't for for 
headers/import files.

Say you create library "foo" and an import file, foo.di. Compiling, say 
main.d, together with foo.di will not link with foo.lib.

> I can imagine a situation where libraries would imply their associated
> lib just by being imported into your module. With a package manager as
> you describe, and source-embedded lib linkage statements, your average
> user would be in a position to never concern themselves with libs at
> all. Sounds almost as good as Java/C#.

Exactly.

> The source -> object files would ideally know, and the linker would
> extract that information its self. I think that's the topic of the
> conversation :)

Yeah, but I don't think it's there it belongs. I would also say that a 
package manager can be more flexible then the current state of 
pragma(lib). When we start to mix in versions and other type of features.

> The linker knows standard places to search, and non-standard places
> would still need to be configured... but this marry's very nicely with a
> package manager as you describe, since there'll never be confusion about
> where to look under that system.

Note that when I say "import path" I'm referring to the path where to 
search for header (.h) files/import files (.di). The linker has nothing 
to do with this.

> The point I'm trying to make is that a solution which is only convenient
> when working with a particular configurable/flexible build script isn't
> a sufficient solution.
> #pragma lib is very convenient, especially in the absence of a
> comprehensive build environment (such as Visual Studio). I maintain that
> there is absolutely nowhere that understands library dependencies better
> than the code that produces that dependency. I'd love to be able to
> describe all linker requirements in that way if I could, regardless of
> the toolchain/operating system.

Well, if it's possible to add flags for the compiler and linker it 
should be possible. If it's possible to create a plugin for VisualStudio 
that can compile D code then I'm sure that plugin needs to be able to 
add these kind of flags.

Instead of specifying libraries and link flags I want to specify 
packages. These packages know which libraries, link flags and other 
dependencies are needed to build with.

> So I am actually all for a package manager for libs, particularly in
> conjunction with #pragma lib. That beautiful union eliminates the linker
> from the things that a programmer cares about almost entirely.

Actually, this works quite nicely in Ruby. In Ruby the package manager 
overrides the standard "require" function, that would be the same as 
overriding "import" in D or "#include" in C/C++. But that's not possible 
for a library to do, so I'm trying my best here.

In Ruby you also don't need any link flags or other compile flags for 
that matter.

> I have my suspicions though that unless it gains universal acceptable by
> the D community, the libs either won't be up to date, or just not
> available - which may be a worse case, in that the management of libs
> would be fractured across multiple management mechanisms.

Absolutely, that is a real problem. But we have to start somewhere. I'm 
drying to do what I think is best and then collect feedback from the 
newsgroups.

-- 
/Jacob Carlborg