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
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
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
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
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
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
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
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,
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
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
Hallo.
Because the discussion on spec file unification de-facto not yet
started, I would like to start it with probably the least problematic
part: autotools based projects. Even there is a lot of things to
discuss.
Packaging autotools based projects - spec file template (draft 1)
These
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 packages on platforms, that was not
supported
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 time of the source release.
autoreconf -f -i
I
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 time of the source release.
Mark Hatle wrote:
In this case the only alternative is to have the last patch be the
equiv of running autoreconf... and you need to ensure the time stamps
are right and such once it's applied or the autotools may run again.
Autotools greatly complicate this. In my experience it's either run
15 matches
Mail list logo
