[Rpm-maint] [draft] spec file unification: autotools based projects
haisenko at comdasys.com
Fri Jul 18 12:36:34 UTC 2008
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)
> > > 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:
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.
Rüdesheimer Str. 7
Tel.: +49 (0)89 548 433 321
More information about the Rpm-maint