Re: [cbi-dev] Some feedback on the build prototype

[Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx>]

On Fri, Dec 23, 2011 at 9:34 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote:

This is not how Tycho, and Maven in general, work. As I mentioned
before, Tycho builds source trees, which in virtually all cases consist
of multiple related projects (or "modules", as in Maven speak) that are
developed and built together. In case of git, this means that all
modules' sources belong to the same checkout.

Yes, we noticed that :-)  It's of the problems the LTS build will have to overcome  to replicate a current Eclipse/Equinox SDK build.  There's a fundamental requirement in build output of the eclipse project builds: the qualifier is the same *iff* the bundle is the same.  Up until now, the map files have provided that, or allowed it to be fixed in the few instances it fails.

You can look at this in 2 ways.  1) going forward, and 2) support for 3.7.x, 3.6.x, 3.5.x, 3.4.x

1) going forward in 3.8 and 4.2, we're all in git.  With the switch to using the integration branch as build input, you are in the situation where the build input is one checkout per repo, the common scenario.  The map files become a secondary, generated set of artifacts which could in theory be bypassed.  Generating the qualifier for each project using the UTC timestamp of the last commit to touch  that project [1] (which is just a convention for our auto-tagging script right now) guarantees that a change in the source generates a new qualifier, and no change in the source generates the same qualifier [2], and would make the maven only build be able to derive qualifiers the same way our current map based builds do.


2)   To regenerate an existing release build, the map files must be read because the qualifiers aren't standardized.  For a given maintenance release I see qualifiers like: I*, M*, r36* v*_r36*, etc.  


How to consume map files is important depending on how important support for #2 is.


Later,
PW


[1] SWT is the exception to this.  Their build qualifier must be the same in their native binaries, their fragments, and their bundle.  Because of this they can't use the auto-tagging convention without re-considering their entire build process.

[2] there's always an exception, of course :-) If you re-run a build but change the basebuilder/compiler out from under the system, you'll get different compiled content even though technically it's the same.  To update qualifiers (sometimes necessary) we are considering using a non-source file with a commit change, so there will be an actual commit in the repo to reflect the need to bump up a qualifier.  This doesn't work while trying to reproduce an old build though.



-- 
Paul Webster
Hi floor.  Make me a sammich! - GIR