<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Sat, 2010-05-29 at 15:26 +0200, Dirk Wallenstein wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Sat, May 29, 2010 at 08:47:04AM -0400, Gaetan Nadon wrote: > > Geode is hardware specific. It does not build on AMD64, 32 bit only. > Look at util/modular/build.sh to find out about platform restrictions. > I haven't look at jhbuild yet, but I don't think it handles platform > filtering. Does this mean you need to maintain one module set for every > permutation of host/cpu? I think it would be possible to introduce another <autotools> attribute that specifies a filename to execute, and the retval says if it is eligible. Then it might be possible that those modules don't appear in the modules list at all. The autotools attribute would ensure that that file to execute is a tracked file and not one accidentally put there. I think the possibility to enable/disable a module depending on external conditions is generally appealing. That would of course require such a file in the modules that don't build everywhere. </PRE> </BLOCKQUOTE> I had similar thoughts. A simple text file would do, listing allowed and forbidden host/cpu, as a naive implementation. Perhaps an xml file could reduce coding effort to read it. Using data encapsulation as a guiding principle, a module should know where it can or cannot be built. Currently the information is in the build scripts, so it needs to be duplicated and maintained in multiple build systems. <BR> <BR> <BLOCKQUOTE TYPE=CITE> <PRE> For now I plan to improve the my.modules file, so that it contains corresponding comments, and include the necessary steps in a future setup tutorial. </PRE> </BLOCKQUOTE> </BODY> </HTML>