I've been thinking about the practical problems of extending the EFS namespace to add new platforms, and new compilers. Adding new platforms is very well thought out, fully automated, and aggressively tested in the EFS test suite itself. Once you have invested a great deal of effort into building our /efs/dist for a given set of platforms, adding a new one which is backwards compatible with one of the existing one's is straight forward. Adding support for a totally new platforms is, and always will be, a lot of work, but the clonerelease and childrelease mechanism help make that manageable as well.
Compilers are another story altogether, and a very different problem. We know from experience that the compiler ABIs are often not compatible at all, for example with C++ gcc3.* and gcc4.* have different name mangling schemes, and code produced with one can not be linked with the other. For perl, 5.8 and 5.10 have different binary ABIs, too. In the efsdeploy config, I define the gcc 4.1.* based compilers as compatible with each other, since in practice they are. I also defined gcc443 as backwards compatible with both gcc411 and rh412, since that allows builds with gcc443 to leverage existing builds made with the 4.1.* based compilers, which tends to work, in general. When/if it doesn't, then you will have to rebuild some infrastructure. The alternative is to be forced to rebuild EVERYTHING, and that;s simply not feasible anymore. Perl is in a similar situation, but for a very different reason. We made the strategic decision to install *nothing* in common anymore, and to force each and every perl module to be installed (and most importantly tested) for each distinct platform/compiler combination, even when the modules are not compiled XS code, and thus there's no binary ABI involved. Now, consider the challenge we face extending /efs/dist/perl5 to support perl5.12. If we have to rebuild each and every module for 5.12, realistically, we're not going to have 5.12 support in a timely fashion. The purist in me (I listen to him once in a while) says that's the Right Thing To Do. The realist in me (I listen to him far more often) laughs at the purist, and points out that we'll simply never get caught up. I think it makes sense, as a migration aid, to define 5.12 as compatible with 5.10. This will allow code like EFS::Perl::Version and EFS::Perl::Depends to leverage the existing 5.10 builds for 5.12, which will work for almost ALL of the non-compiled code. Once you do this, then you immediately begin compiling *new* releases for all 3: 5.8, 5.10 and 5.12. Over time, you will have more and more "native" builds of modules for 5.12, but you can start using 5.12 right away, and are only required to rebuild the modules that are truly compiled. You're in the same boat you would have been in if you didn't define it as compatible. The difference is that instead of "module not found" errors, you'll get compile time errors when the ABI doesn't match. So what -- that's cosmetic. A failure is a failure. This is essentially the same policy we should have for new platforms, too. When a new platform is defined in the environment we make it backwards compatible with previous OS releases, extend the existing .exec namespaces with commands like "efs execlinks any", and are able to instantly leverage the new platform, heavily leveraging backwards compatibility. New releases should be build natively on as many platforms as possible (something we have NOT started doing systematically, but which efsdeploy will make far easier), and over time, you get more and more native binaries. I think it should be obvious to everyone that EFS can NOT possible scale if we require the addition of a new platform of compiler to require a global rebuild. The effort involved is tremendous, and we need to be able to extend support to these newer platforms faster than the time required to get everything "perfect" for it. Backwards compatibility has to be our friend here.
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
