Miguel, I should emphasize that conditional load/compile in Metacello is a pragmatic feature. I don't disagree that the combinatorials can quickly spiral out of control, but for the short term there is no alternative. I won't argue that conditionals _should_ be included in the package management layer, either.
As with all other problems there are several ways to "skin the cat". I _could_ have extended Monticello to have platform-specific code components. I _could_ have added conditional compilation to the Smalltalk compiler. In many ways those solutions are uglier than putting conditional loading into Metacello:) In the end I added the minimum set of features to Metacello that solved the problems that I was facing on a daily basis and conditional load/compile was high on my list. With that said, I encourage and support any effort aimed at avoided the use of conditionals:) Dale ----- "Dale Henrichs" <[email protected]> wrote: | Miguel, | | Keep in mind that the conditional load code in Metacello is the moral | equivalent of #ifdef in C. The debian package universe has the | advantage of pushing the conditional compilaton of _source code_ down | a level. | | With Metacello, I purposely use the version attribute for conditional | loading of code (as close to a conditional compile as you can get). In | Metacello we do the load and the compile... | | Where common code can be written it should be, but as versions and | platforms diverge in their API, something has to give ... If you can | afford to seal off the source code for an older version then that's | fine, but in a project that is under active development and is | _expected_ to run on multiple versions of multiple platforms one must | resort to "conditional loading" - conditional loading is what makes | Grease work, BTW. | | When you look at the universe of #ifdef in C, you see that some of the | ifdefs are adhoc and some of the ifdefs are based upon platform | constants ... and that is what the metacello attributes give you ... | Right now, you can create project-specific attributes and there are a | handful of pre-defined attributes ... As I said, I am purposefully | avoiding adding new pre-defined attributes willy nilly, but anticipate | that some will be needed (GemStone3.0 and GemStone2.4 and even | GemStone2.3 need to have difference code compiled/loaded for projects | that are in active developement and expect to be run on all three | versions of GemStone the low-level apis are different and different | code has to be written for each different version). | | Having the conditional compile/load component in Metacello isn't | necessarily an elegant feature, but given that no other part of the | Smalltalk system currently provides a conditional compile/load, I | added it to Metacello. Since I am maintaining common software on three | different versions of gemstone, I consider it a requirement. | | If and when an elegant conditional compile/load solution becomes | available, then this particular feature of Metacello can be allowed to | die in peace. | | I will agree that the MYSQL maintainers don't worry whether their | executables load on Ubuntu or Fedora, but I can almost guarantee you | that they have conditional code that makes sure that there their code | will compile/build on the different OSes. | | The ifdef world is as ugly as it comes, but it does exists for a | pretty good reason. | | | Dale | ----- "Miguel Enrique Cobá Martinez" <[email protected]> wrote: | | | El sáb, 20-03-2010 a las 21:54 +0300, George Herolyants escribió: | | > Thanks for the explanation, Dale! | | > | | > May be it's obvious and I'm asking stupid questions but then I | | don't | | > understand how can I specify in my configuration the differences | | > between the versions of the target platform? | | > | | > 2010/3/20 Dale Henrichs <[email protected]>: | | > > George, | | > > | | > > The mcz files containing the Metacello configurations _are_ | | copied, but the configuration itself is not modified in the scheme. | | > > | | > > The idea of using different repositories is to indicate which of | | the many different projects are _expected_ or _known_ to work in | | Pharo1.1 or Pharo1.0. | | > > | | > > For GemStone, I have createed a GemSource MetacelloRepository | and | | I have copied the metacello configurations that I know have been | | ported to GemStone. I've done this so that folks can know what is | | supported. I make sure that all of the tests run green and that all | of | | the configs in the GemSource MetacelloRepository can be loaded. | | > > | | > > It does not stop someone from loading a configuration into | | GemStone that isn't in the GemSource MetacelloRepository, but if you | | do and run into trouble, my answer will probably be that it hasn't | | been ported yet. | | > > | | > > The same thing can apply to Squeak, but someone would have to | step | | up to testing/approving metacello configurations that run with the | | various versions. | | > > | | > > Without this extra step of approval/testing, it's difficult for | | someone that doesn't have their finger on the pulse of the latest | and | | greatest happenings to know what to expect ... | | > > | | > > Dale | | | | The problem is, you are thinking in upstream development, and the | | idea | | of universes is that each package has maintainer for each platform | | involved. This maintainer can be the same person that the upstream | | developer, but it can also be someone else that make sure that a | | given | | package load correctly in *a give* fork. | | | | Making an analogy, what you are saying is that the maintainers of | | MySQL | | deb package in Debian should be worried about the package not | loading | | in | | Ubuntu or Fedora. That is not the case. The upstream code can run in | | all | | of three distros, but the packages specific to each one (.deb in | | debian | | and ubuntu and .rpm in fedora) *must* be build and tested for their | | own | | maintainers. The upstream developers can rightfully don't give a | dime | | about where is package is being used and maybe they only release | | a .tar.gz and know nothing (but also they don't stop efforts) about | | external package for specific distros. | | | | So, returning to your question, maybe sometime in the future Squeak | | (if | | interested) will have to build its own repositories with its own | | universes and put there the configurations that are proved to work | in | | Squeak. | | | | Right now as Pharo and Squeak are very similar the configurations | | (and | | the #common you mention) works, but this isn't going to scale for | | different Smalltalks in the long term. | | | | Cheers | | > | | > _______________________________________________ | | > Pharo-project mailing list | | > [email protected] | | > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | | -- | | Miguel Cobá | | http://miguel.leugim.com.mx | | _______________________________________________ | Pharo-project mailing list | [email protected] | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
