#pragma comment (lib, ...)

Manu turkeyman at gmail.com
Thu Oct 11 04:22:19 PDT 2012


On 11 October 2012 12:04, Jacob Carlborg <doob at me.com> wrote:

> On 2012-10-11 10:12, Manu wrote:
>
>  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.
>>
>
> RubyGems is working perfectly fine on Windows. Just because most Windows
> does not have a built in package manager and most of these open source
> language seems to lean towards Posix than Windows doesn't mean that you
> can't have a working package manager in Windows.


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.

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 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#.


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?
>>
>
> So what does know which libraries to link with if not the build script.
> Something needs to know that.


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 :)


The linker would just need to be smart enough to gather the deps from
>> the objects while linking.
>>
>
> The linker doesn't know anything about the import paths.
>

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.


Does it work in windows and integrate with Visual Studio?
>> If not, sadly, it's irrelevant.
>>
>
> Of course, I build all by software to work cross-platform, what is
> pointing to anything else.
>
> You're talking about "working on all platforms" but then you end with this
> comment making the rest of your comments not very believable.
>
> I can end with the same comment. Does Visual Studio work on other
> platforms than Windows? No, then it's irrelevant.
>

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.

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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121011/651c6b2d/attachment-0001.html>


More information about the Digitalmars-d mailing list