Package manager - interacting with the compiler

[J Arrizza]

Jacob,

On Sat, Dec 10, 2011 at 12:55 AM, Jacob Carlborg <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.


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111210/f18cc9ac/attachment.html>