Package manager - interacting with the compiler

[Martin Nowak]

On Sun, 11 Dec 2011 22:15:26 +0100, Jacob Carlborg <doob at me.com> wrote:

> On 2011-12-10 22:13, J Arrizza wrote:
>> Jacob,
>>
>> On Sat, Dec 10, 2011 at 12:55 AM, Jacob Carlborg <doob at me.com
>> <mailto:doob at me.com>> wrote:
>>
>>     Currently I see two use cases:
>>
>>     1. When the package manager installs (and builds) a package
>>
>>
>> This will have to handle cross-compilations and multiple build variants
>> per platform. Multiple platforms are needed especially for embedded work
>> (simulation vs real binaries) and multiple build variants are needed, at
>> least Debug vs Release variants.
>>
>> Also multiple projects require a set of config files per project. There
>> would be a lot of commonality between project config files but that's
>> ok. The idea of "inheriting" from a common config  file can cause a lot
>> of problems.
>>
>> In all cases, the config file(s) need to be version controlled per
>> project since they are unique to the project generating the build.
>
> The package manager just invokes a build tool, like make, rdmd, dsss,  
> shell script and so on.
>
>>     2. When a user (developer) builds a project and want's to use
>>     installed packages
>>
>>
>>     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).
>>
>> Please no environment variables for anything. If all config info is in a
>> file and that file is version controlled then keeping tight control over
>> build configurations is much easier.
>>
>> For the same reasons, it would be ideal to have a method that dumps all
>> versions of all packages used by a particular build variant. This could
>> be generated and saved in version control for audit reasons, or, to go
>> the extra step, it could be compared against during every build. This
>> ensures that all components have not been inadvertently changed, i.e.
>> all config changes are done in a controlled way.
>>
>> I'm not sure if any of that points the way to implement the builds any
>> clearer...
>>
>> John
>
> I'm not sure but I think you missed the point (or I missed your point).  
> The projects will have a file indicating which other project they  
> depends on. The when the package manager installs a project it will  
> compile the project. When it's compiled the package manager needs to  
> somehow tell the compiler what imports path to use and libraries to link  
> with.
>

I think a useful approach is to implement
http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP13
and map import paths to packages. It allows to handle different versions
and hide undeclared dependencies, i.e. no accidental imports.
As this only works when building packages every installed package
should have a symlink for their most recent version in a common
import directory so that plain dmd builds can use the packages.

martin