On 2011-12-10 22:17, jdrewsen wrote:
On Saturday, 10 December 2011 at 08:55:57 UTC, Jacob Carlborg wrote:
I think I've come so far in my development of a package manager that
it's time to think how it should interact with the compiler.
Currently I see two use cases:
1. When the package manager installs (and builds) a package
2. When a user (developer) builds a project and want's to use
installed packages
In the best of worlds the user wouldn't have to do anything and it
just works. The package manger needs to somehow pass import paths to
the compiler and libraries to link with.
I'm not entirely sure what the best method to do this would be. But
I'm thinking that if the compiler could accept compiler flags passed
via environment variables use case 1 would be easy to implement.
For use case 2 it would be a bit more problematic. In this use case
the user would need to somehow tell the package manager that I want to
use these packages, something like:
// project.obspec
orb "foo"
orb "bar"
$ orb use project.obspec
or for single packages
$ orb use foobar
$ dmd project.d
If environment variables are used in this case, then the package
manager would need a shell script wrapper, the same way as DVM does
it, to be able to set environment variables for the parent (the
shell). The reason for this is that a child process (the package
manager) can't set environment variables for the parent process (the
shell). This complicates the implementation and installation of the
package manager and requires different implementations for Posix and
Windows.
Another idea would be to manipulate the dmd.conf/sc.ini file but that
seems to be quite complicated and messy. On the other hand, this
wouldn't require any changes to the compiler.
Any other ideas?
https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
https://github.com/jacob-carlborg/orbit
For use case 1 the package manager could just as well call dmd directly
with the correct flags ie. no need for using environment variables.
I was thinking that the package manager just invokes a build tool like
make, rdmd, dsss, shell script and so on.
Use case 2 does not belong to a package manager in my opinion. It is the job
of a build tool to configure packages for a project. What would be nice
to have support for using packages without a build tool. Maybe something
like what pkg-config provides:
dmd -ofhello `orb -lib foo` hello.d where "org -lib foo" returns the
flags to use the foo package.
/Jonas
I would say that the preferred way is to use a build tool then there is
no problem. The build tool just asks the package manager which import
paths to use for the given packages and pass the information to the
compiler. But I don't want my package manager to depend on a built tool,
I want it to be usable on its own.
--
/Jacob Carlborg
