<div><div class="gmail_quote">Jacob,</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Sat, Dec 10, 2011 at 12:55 AM, Jacob Carlborg <span dir="ltr"><<a href="mailto:doob@me.com">doob@me.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently I see two use cases:<br>
<br>
1. When the package manager installs (and builds) a package<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div><div>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.</div>
</div><div><br></div><div>In all cases, the config file(s) need to be version controlled per project since they are unique to the project generating the build.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

2. When a user (developer) builds a project and want's to use installed packages<br>
 </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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). </blockquote><div>
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.</div><div><br></div><div>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.</div>
<div><br></div><div>I'm not sure if any of that points the way to implement the builds any clearer...</div><div><br></div><div>John</div><div><br></div></div>
</div>