xf86-video-geode build error running jhbuild

[Dirk Wallenstein]

On Sat, May 29, 2010 at 10:14:21AM -0400, Gaetan Nadon wrote:
>    On Sat, 2010-05-29 at 15:26 +0200, Dirk Wallenstein wrote:
> 
> 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.
> 
> 
>    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.

Sounds good.

> 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.

Ah! Much simpler. The new internal 'init' command that creates a
repo-group local configuration, can simply fill out the list of modules
to skip. However, that relies on module-names, it needs to be kept up to
date, and the user has to drag it along if an alternative configuration
for the same repo-group is wanted.

That would of course allow to mix in all the libs and drivers into the
main meta module and let 'init' sort it out. Very good.

Coming soon...

-- 
Greetings,
Dirk