#pragma comment (lib, ...)

[Paulo Pinto]

On Thursday, 11 October 2012 at 11:46:39 UTC, Manu wrote:
> 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.

For those of us doing .NET development, the answer is NuGet.
http://visualstudiogallery.msdn.microsoft.com/27077b70-9dad-4c64-adcf-c7cf6bc9970c

And there is already a package manager for Windows that uses 
NuGet as infrastructure.

http://chocolatey.org/

--
Paulo