On Sunday, 11 December 2011 at 21:22:37 UTC, Jacob Carlborg wrote:
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.
And for that I think the pkg-config method is the way to go.
Setting environment vars brings unneeded state into you
development session.
Another option would be to just wrap dmd in a e.g. orbdmd command
and handle it there.
Btw: have you considered renaming from orb to something that
makes sense to newbies e.g. dpack?
-Jonas
