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

2008-07-18 Thread Stanislav Brabec
Hans de Goede wrote: Ralf Corsepius wrote: On Thu, 2008-07-17 at 17:09 +0200, Stanislav Brabec wrote: Hallo. %build Packagers are encouraged to call autoreconf whenever possible. It guarantees correct build of packages on platforms, that was not supported by autotools in the

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

2008-07-18 Thread Stanislav Brabec
Mark Hatle wrote: Stanislav Brabec wrote: The standard %setup macro should unpack these packages in convenient way: %prep %setup -q Configuration and compilation %build Packagers are encouraged to call autoreconf whenever possible. It guarantees correct build of

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

2008-07-18 Thread Stanislav Brabec
Ralf Corsepius wrote: 1. We are not in different positions. You might not be aware about it, but Hans, Bill and I all package many packages in Fedora, comprising more than i386 and x86_64. 2. If what you claim was true, either the packages you are dealing with are of low quality or there

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

2008-07-18 Thread Stanislav Brabec
Marc Haisenko wrote: What about passing autoconf cache variables ? I regularly need to do things like: ac_cv_foo=yes \ ac_cv_bar=no \ ./configure ... It should not appear in the spec files, as it is not packages specific, but platform specific. Hopefully autotools provide a support for

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

2008-07-18 Thread Marc Haisenko
On Friday 18 July 2008, Stanislav Brabec wrote: Marc Haisenko wrote: What about passing autoconf cache variables ? I regularly need to do things like: ac_cv_foo=yes \ ac_cv_bar=no \ ./configure ... It should not appear in the spec files, as it is not packages specific, but platform

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

2008-07-18 Thread Stanislav Brabec
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

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

2008-07-18 Thread 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

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

2008-07-18 Thread Pavol Rusnak
Stanislav Brabec wrote: Attached script changes all references to %{_libdir} form. It is far from being perfect, but it helps a bit. By choosing the right order of replacements we could use less rules to have the same effect. I'm attaching a modified script. -- Best Regards / S pozdravom,

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

2008-07-18 Thread Mark Hatle
Marc Haisenko wrote: 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

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

2008-07-18 Thread Stanislav Brabec
Mark Hatle wrote: Stanislav Brabec wrote: - And finally gcc itself has no support for explicit -I and -L redirection into sysroot. -L=... That is a built in option that allows redirect into the sysroot automatically. -L= is at least recognized by ld. Our toolchains enable -I= as