On Friday 18 July 2008, Stanislav Brabec wrote: > Marc Haisenko wrote: > > > Hopefully autotools provide a support for system-wide caches and > > > settings. > > > > > > You could create a global cache of these variables (for example > > > OpenEmbedded does). You can modify definition of %configure or define > > > extra variables in your global RPM macros to build it with this cache, > > > or do some config.site magic. > > > > And how is that supposed to work ? I would need a way for each spec to > > tell RPM "I'm now compiling for environment X, grab me the appropiate > > %configure". I'm cross-compiling to several different architectures, if I > > were to only cross-compile to one then your suggestions would make sense > > to me. > > Implant "export CONFIG_SITE=/my/armeb.site" variable somewhere into the > rpmbuild environment. > The file should look as follows (see the end of this mail)
Interesting idea. > > > Regarding the cross compilation, autotools have much more problems than > > > rpmbuild, so we are still very far from the situation, when unpatched > > > standard spec files could be usable for cross compilation. > > > > I don't think this will ever be possible :-) And I don't think that this > > should be a goal. I just wanted to remind that there ARE situations in > > which you need to pass cache variables to autoconf and I don't want to > > "export" them when I need them only for one command (configure). > > I think at would be possible, however it still means a lot of work: > http://idea.opensuse.org/content/ideas/design-and-implement-sysroot-support >-for-cross-compilation-environment?s=cross Yeah, sys-root support for the autotools would be great, especially if they would automatically derive the correct sys-root from GCC. But I rarely have any problems with configure finding the correct includes and libraries, both with and without sys-root cross-gcc's. But if configure would be able to ALSO find some libraries for the HOST_CC this would be great. > I can imagine: > > # Compile for target and not install > noinst_PROGRAMS = demo1 demo2 > > # Compile for build host and not install > noinst_NATIVE_PROGRAMS = parsedoc > > # Compile for both > extratools_NATIVEPROGRAMS = myproject-prepare-source > > extratoolsdir = $(libexecdir)/myproject > > extra_NATIVEPROGRAMS_LIBADD = -lintl $(GTK_LIBS) > > extra_NATIVEPROGRAMS_NATIVELIBADD = $(NATIVE_GTK_LIBS) > > (Well, still not polished idea: Imagine, that you don't want to write > twice, that GTK_LIBS are needed for both builds.) > > ... And I can imagine amount of work it would requiere. Something like this would be nice, yes. Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint