#pragma comment (lib, ...)

[Jacob Carlborg]

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.

> I've never seen the 'custom build tool' option in Visual Studio (and if
> there were one, certainly people don't use it). And no associated
> package manager that automatically fetches dependencies...

What's stopping anyone from adding support for this in VisualD?

> Additionally, you're insisting build tool 'X' upon people, and I presume
> it's not an established 'standard' build tool that's accepted/agreed on
> all platforms. You'll never convince people to use it, and certainly not
> in in proprietary situations where your tools are dictated.

Then tell me what established standard build tool that works cross 
platform. They're just pain in the ass to use or have too many 
dependencies to use/too complicated to install.

I'm not forcing anyone upon my tools. But you're trying to force 
features into D that is not particular useful.

> This is indeed ridiculous, but trivial. I'm sure it can be fixed in minutes.
> I don't think the solution is complicated, given a lib name, on linux it
> first looks for a lib*.so, then for a .a. Windows uses import libs,
> which will be resolved exactly the same as a static lib, and I don't
> know anything about OSX, is it not similar/same as linux?

No, Mac OS X uses .dylib files. In addition to that it uses frameworks 
and other kind of bundles. A framework is a folder that the linker and 
Finder (file browser) treats differently. It contains a dynamic library, 
headers and other resources like images. It has the .framework extension.

>     Another point is that I don't want to separate the build script.
>     Compile and link flags in one file and then the libraries to link
>     with in a different file? That's just stupid.
>
>
> What's a flag? you mean those little options in the property grid when
> you Right Click->Properties on the project? ;)

No, I mean when you left click. How the hell would I know what tools 
you're using?

> People don't like doing that, and they really hate micro-managing a
> massive list of libraries in there. Also those flags aren't
> configurable, you can't just add one for your new feature of interest.

So how do you chooses what libraries to link with. If you want to build 
in a release or a debug build. Regardless what tools you have, in the 
end it will add compile and link flags somewhere.

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

> This is annoying in a cross-platform environment, because all platforms
> tend to link a totally different set of libraries, and that means your
> build script is cluttered with annoying manually maintained lists for
> each platform, and the less commonly used/built platform ALWAYS seems to
> fall out of date.

The information needs to be somewhere.

> In D's context, D has very powerful (and more manageable) static logic,
> I can see it being even more useful to have code-driven selection of
> dependencies in D than it already is in C.
>
>
>     With the approach with the build tool and the package manager
>     working together the build tool can also automatically specify the
>     path to the import files. How would you do that in a source file?
>     Either the compiler would always need to read a special file first.
>     Or it would need to scan all files for a particular pragma to get
>     the import paths. Then it would rescan the files again during the
>     actual compilation.
>
>
> 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.

> I've said before, my question is: is it _possible_ to do it in a cross
> platform way currently? I see some other comments with ideas, maybe it is?
>
>
>     This is a specification/description of a package manager I'm working on:
>
>     https://github.com/jacob-__carlborg/orbit/wiki/Orbit-__Package-Manager-for-D
>     <https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D>
>
>
> 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.

I care about cross-platform not just about Windows and/or Visual Stdio. 
I build my tools as libraries make it easy to both create command line 
tools or plugins to integrate in whatever IDE/application you want to 
use. Not just a plugin specifically for Visual Studio.

> But aside from that, I am curious, what makes it better/more useful than
> apt?

It's specific to D and can be made a lot more easier to work with. apt 
doesn't know anything about D, DMD or how to build a D application. apt 
is also only works on Debian, Ubuntu and a few other Linux distributions.

-- 
/Jacob Carlborg