Package manager - interacting with the compiler

[Jacob Carlborg]

On 2011-12-12 01:36, Martin Nowak wrote:
> 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

I don't like the ideas in that DIP. I don't think the packages should 
have symlinks to a common import directory. It will cause problems if 
the top level package of a library has the same name as some other 
library, like it is with DWT:

org.eclipse.swt
org.eclipse.jface

And so on.

-- 
/Jacob Carlborg