General development/structure notes.Nothing atm. 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 emerge logic. |
|