On 11 October 2012 12:04, Jacob Carlborg <span dir="ltr"><<a href="mailto:doob@me.com" target="_blank">doob@me.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2012-10-11 10:12, Manu wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sorry, I do know what a package manager is. I was being facetious, in<br>
that windows has no such concept, and most people use windows.<br>
It's not practical to depend on anything like that.<br>
</blockquote>
<br></div>
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.</blockquote>
<div><br></div><div>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.</div><div>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?</div>
<div>An inflexible build system like Visual Studio doesn't really handle that very well.</div><div><br></div><div>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.</div>
<div><br></div><div>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#.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I also maintain that it's not stupid. The build script doesn't know what</blockquote></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
libs the code will link to. I guess you're arguing that your<br>
build-script should exclusively define the features/libs, not the other<br>
way around?<br>
</blockquote>
<br></div>
So what does know which libraries to link with if not the build script. Something needs to know that.</blockquote><div><br></div><div>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 :)</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"></div><div class="im">
The linker would just need to be smart enough to gather the deps from<br>
the objects while linking.<br>
</div></blockquote>
<br>
The linker doesn't know anything about the import paths.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Does it work in windows and integrate with Visual Studio?<br>
If not, sadly, it's irrelevant.<br>
</div></blockquote>
<br>
Of course, I build all by software to work cross-platform, what is pointing to anything else.<br>
<br>
You're talking about "working on all platforms" but then you end with this comment making the rest of your comments not very believable.<br>
<br>
I can end with the same comment. Does Visual Studio work on other platforms than Windows? No, then it's irrelevant.<br></blockquote><div><br></div><div>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.</div>
<div>#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.</div>
<div><br></div><div>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.</div>
<div>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.</div>
</div>