[Rpm-maint] [draft] spec file unification: autotools based projects

[Marc Haisenko]

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