General development/structure notes.
Asis needs to be unmerged for minor update.
This entry refers to the blocker in asis ebuilds, where user is asked to unmerge
asis on update. A rather trivial issue. However, as I already tried looking into
reimplementing how it is build, only to roll it back later, it makes sense to
document the reasons behind present design.
Asis is basically an extention of gcc. As such, it needs to be installed along
with gcc components. Later, when asis gets updated, it preferentially finds old asis
instance and tries to use those sources/libs instead of new material. Most often this
leads to to broken build, but, even if it builds, may cause inconsistencies later. Since,
being part of gcc, old asis cannot be masked, the easy way out is to force unmerging of old
version on update.
It is tempting to consider changing the build process, to remove this need to unmerge asis.
However, this would require installing asis some place away from the rest of gnat. This
leads to duplication of most of env vars controlling active gnat. Which, in turn, seems
more trouble than having to unmerge asis once in a while before update.
Another approach would be to try to build gnat under the control of gnatbuild.eclass. Asis
is just an extention of gnat, isn't it? So lets build them at the same time! Unfortunately,
asis build process does not work like that. It requires an already installed gnat. We could
reset some vars to bend where asis looks for gnat after it has been built. However, this
essentially forces multiple emerge phases to take place within comile phase. We would have
to (1) build then (2) install gnat then go back to (3) building asis then (4) installing
it. Only afterwards we can finish the build and go to install pahse of the whole. We might
also need to provide a hook to modify sources in between (2) and (3). In short, this is way
beyond the reasonable build adjustments, not even mentioning how this would screw normal