Package manager - interacting with the compiler

[jdrewsen]

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