On 2012-10-10 14:59, Manu wrote:
None of those things actually embody the information about the
relationship, nor can they. The source code does, and nothing else.
Features that imply the dependency may (and often are) be disabled at
compile time.
I rather like that the compiler is able to put a note in the object file
that it depends on a particular lib, because it does.
I'm not sure how a package manager helps... What is a package manager? ;)
I'd like to hear some reasons why that is a bad or undesirable thing, or
is this just an opinion?
A package manager is a tool that downloads and installs libraries, application and tools, also known as packages. It also tracks and installs all the dependencies of a package automatically. RubyGems, CPAN, PEAR, npm are a couple of examples of package managers specifically made for a programming language.
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.
This is my vision (simplified) of how build tool, package manager and the compiler work together.
# build script
package foo
package bar
files myapp/main.d
$ build myapp
The build tool "build" will read the build script and see that it has two dependencies: "foo" and "bar". The build tool will get information from the package manager about these packages. Information like the path to the import files/source/headers and the path to the library to link with.
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...
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.
The build tool will then simply invoke the compiler with the correct flags to be able to build and link with these libraries. The build tool will, of course, know the platform it runs on so it can call the compiler with different flags depending on the platform. On Posix it would probably link to "libfoo.a" where on Windows it would link to "foo.lib".
If I recall correctly, using pragma(lib) with dmd, you need to specify the extension for the library, ending up with code like this:
version (Posix)
pragma(lib, "foo.lib");
else version (Windows)
pragma(lib, "libfoo.a");
Which is just ridiculous. Sure you could change DMD to support for this. But what happens with dynamic libraries? .dll on Windows, .so on Linux/BSD and .dylib on Mac OS X. Then on Mac OS X there are various other types of dynamic libraries, like frameworks and bundles, with their own extension.
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?
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? ;)
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.
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?
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.
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.
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
Does it work in windows and integrate with Visual Studio?
If not, sadly, it's irrelevant.
But aside from that, I am curious, what makes it better/more useful than apt?