I seem to recall discussion on this in the ancient past, but I couldn't find anything in the archive, nor on the current Fedora Packaging Guidelines docs.
There exist upstreams out there that are written in C/C++ but don't ship with a "configure" script. In some cases, I've seen this addressed by simply not running the %configure macro and then make-ing as normal, or by manually using %optflags somewhere. This is the suggestion in some tutorials for addressing this, e.g.: https://rpm-packaging-guide.github.io/#cello-working-with-spec-files
The %build section is where we tell the system how to actually build the software we are packaging. Since wrote a simple Makefile for our C implementation, we can simply use the GNU make command provided by rpmdev-newspec. However, we need to remove the call to %configure because we did not provide a configure script
I'd like to propose the addition of a "Configuration" section in the FPG (probably right under https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler ) that addresses the importance of using %configure. It ensures flags are properly exported into the environment, but could also do other arbitrary, distro-dependent things at some point, so it's still better to run the macro than not. There are two possible workarounds, depending on the whether %_configure (with underscore) is available, or if more control is needed for simulating a script.
Safer:
%build # source has no configure script; use macro anyway echo "#!/bin/sh" > configure ; chmod +x configure
%configure make %{?_smp_mflags}
Recent versions; simple case:
%build # source has no configure script; use macro anyway %define _configure /bin/true
%configure make %{?_smp_mflags}
I submitted https://github.com/redhat-developer/rpm-packaging-guide/issues/75 for that doc, but it seems like something about whether/how to work around this should be in these guidelines too, since they're used so much as a general reference.
Regards, -jc
"JC" == Japheth Cleaver cleaver@terabithia.org writes:
JC> I'd like to propose the addition of a "Configuration" section in the JC> FPG (probably right under JC> https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler JC> ) that addresses the importance of using %configure.
But I don't see what the point of using %configure would be when the software being built does not have make use of autotools.
It seems your concern is the build flags, so why not just use %set_build_flags? %configure does that first, then goes through and modifies various autotools-related things and finally calls the configure script. It seems that nothing but %set_build_flags is relevant at all when autotools isn't in use.
- J<
On 8/27/2019 11:30 AM, Jason L Tibbitts III wrote:
"JC" == Japheth Cleaver cleaver@terabithia.org writes:
JC> I'd like to propose the addition of a "Configuration" section in the JC> FPG (probably right under JC> https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler JC> ) that addresses the importance of using %configure.
But I don't see what the point of using %configure would be when the software being built does not have make use of autotools.
It seems your concern is the build flags, so why not just use %set_build_flags? %configure does that first, then goes through and modifies various autotools-related things and finally calls the configure script. It seems that nothing but %set_build_flags is relevant at all when autotools isn't in use.
I'd say that will *probably* be the case and could be a safe option, but %configure could always have more actions added to it. Since if we run make, we're running an arbitrary Makefile... future-proofing might be good.
%configure is also an omnipresent macro that anyone w/ even a basic understanding of specs will grok, while %set_build_flags is a bit more obscure.
-jc
"JC" == Japheth Cleaver cleaver@terabithia.org writes:
JC> I'd say that will *probably* be the case and could be a safe option, JC> but %configure could always have more actions added to it.
More autotools-related actions, sure, but that wouldn't be relevant to what you're proposing because you're explicitly referencing the case where autotools isn't used.
JC> Since if we run make, we're running an arbitrary JC> Makefile... future-proofing might be good.
I don't understand how future-proofing comes into this. Seems more logical that you would avoid using %configure when autotools isn't in use because it would potentially assume that autotools is actually in use. Avoiding the use of something in situations where it's explicitly not intended to be used seems much more future-proof to me.
JC> %configure is also an omnipresent macro that anyone w/ even a basic JC> understanding of specs will grok,
%configure is certainly present in packages which use autotools; I won't argue that. It's definitely not present the vast majority of packages. Not most rust or go or python or perl or nodejs packages. Not in packages which use, say, meson or cmake as the build system. That really doesn't seem to me to rise to the level of "omnipresent".
JC> while %set_build_flags is a bit more obscure.
%set_build_flags is simply the intended way to accomplish what you're trying to accomplish. Adding a rather obscure creation of a fake configure script just so you can use another macro that you find less obscure doesn't feel like it's doing much in the way of reducing obscurity.
- J<
On 8/27/2019 12:22 PM, Jason L Tibbitts III wrote:
JC> while %set_build_flags is a bit more obscure.
%set_build_flags is simply the intended way to accomplish what you're trying to accomplish. Adding a rather obscure creation of a fake configure script just so you can use another macro that you find less obscure doesn't feel like it's doing much in the way of reducing obscurity.
While I can understand that, I wasn't aware of that macro at all until you brought it up... as were it seems several others.
Although I believe _configure overriding is simpler, I'd be fine with either. I just think some sort of official advice for the situation is warranted.
Also, FTR seems that in EL6 at least not only does %configure not incorporate that, but %set_build_flags does something a bit different.
Not sure if that's a bug there:
-14: set_build_flags CFLAGS="${CFLAGS:-%{build_cflags}}" ; export CFLAGS ; CXXFLAGS="${CXXFLAGS:-%{build_cxxflags}}" ; export CXXFLAGS ; FFLAGS="${FFLAGS:-%{build_fflags}}" ; export FFLAGS ; FCFLAGS="${FCFLAGS:-%{build_fflags}}" ; export FCFLAGS ; LDFLAGS="${LDFLAGS:-%{build_ldflags}}" ; export LDFLAGS
-14: configure CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; FFLAGS="${FFLAGS:-%optflags -I%_fmoddir}" ; export FFLAGS ; %{_configure} --build=%{_build} --host=%{_host} \ (etc)
-jc
On 8/27/2019 12:22 PM, Jason L Tibbitts III wrote:
JC> while %set_build_flags is a bit more obscure.
%set_build_flags is simply the intended way to accomplish what you're trying to accomplish. Adding a rather obscure creation of a fake configure script just so you can use another macro that you find less obscure doesn't feel like it's doing much in the way of reducing obscurity.
While I can understand that, I wasn't aware of that macro at all until you brought it up... as were it seems several others.
Although I believe _configure overriding is simpler, I'd be fine with either. I just think some sort of official advice for the situation is warranted.
Also, FTR seems that in EL6 at least not only does %configure not incorporate that, but %set_build_flags does something a bit different.
Not sure if that's a bug there:
-14: set_build_flags CFLAGS="${CFLAGS:-%{build_cflags}}" ; export CFLAGS ; CXXFLAGS="${CXXFLAGS:-%{build_cxxflags}}" ; export CXXFLAGS ; FFLAGS="${FFLAGS:-%{build_fflags}}" ; export FFLAGS ; FCFLAGS="${FCFLAGS:-%{build_fflags}}" ; export FCFLAGS ; LDFLAGS="${LDFLAGS:-%{build_ldflags}}" ; export LDFLAGS
-14: configure CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; FFLAGS="${FFLAGS:-%optflags -I%_fmoddir}" ; export FFLAGS ; %{_configure} --build=%{_build} --host=%{_host} \ (etc)
-jc
On 8/27/2019 12:22 PM, Jason L Tibbitts III wrote:
JC> while %set_build_flags is a bit more obscure.
%set_build_flags is simply the intended way to accomplish what you're trying to accomplish. Adding a rather obscure creation of a fake configure script just so you can use another macro that you find less obscure doesn't feel like it's doing much in the way of reducing obscurity.
While I can understand that, I wasn't aware of that macro at all until you brought it up... as were it seems several others.
Although I believe _configure overriding is simpler, I'd be fine with either. I just think some sort of official advice for the situation is warranted.
Also, FTR seems that in EL6 at least not only does %configure not incorporate that, but %set_build_flags does something a bit different.
Not sure if that's a bug there:
-14: set_build_flags CFLAGS="${CFLAGS:-%{build_cflags}}" ; export CFLAGS ; CXXFLAGS="${CXXFLAGS:-%{build_cxxflags}}" ; export CXXFLAGS ; FFLAGS="${FFLAGS:-%{build_fflags}}" ; export FFLAGS ; FCFLAGS="${FCFLAGS:-%{build_fflags}}" ; export FCFLAGS ; LDFLAGS="${LDFLAGS:-%{build_ldflags}}" ; export LDFLAGS
-14: configure CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; FFLAGS="${FFLAGS:-%optflags -I%_fmoddir}" ; export FFLAGS ; %{_configure} --build=%{_build} --host=%{_host} \ (etc)
-jc
On Tue, Aug 27, 2019 at 2:31 PM Jason L Tibbitts III tibbs@math.uh.edu wrote:
It seems your concern is the build flags, so why not just use %set_build_flags? %configure does that first, then goes through and modifies various autotools-related things and finally calls the configure script. It seems that nothing but %set_build_flags is relevant at all when autotools isn't in use.
Sort of a tangent, but I'm curious-- is this macro documented somewhere else in the guidelines? Is this a relatively new macro?
I've written several specs which manually set CFLAGS/LDFLAGS in non-automake setups and I had no idea I could just use %set_build_flags to do that for me. It seems pretty useful, I regret not knowing about it before now.
Ben Rosser
"BR" == Ben Rosser rosser.bjr@gmail.com writes:
BR> Sort of a tangent, but I'm curious-- is this macro documented BR> somewhere else in the guidelines? Is this a relatively new macro?
It could probably be better documented, but that's not much different from most RPM macros. Of the top of my head I do not know when it was introduced but it exists in Fedora 29 and works as far back as EPEL6 (via epel-rpm-macros).
It certainly wouldn't be a bad idea for the guidelines to mention it.
- J<
On 27. 08. 19 21:10, Ben Rosser wrote:
On Tue, Aug 27, 2019 at 2:31 PM Jason L Tibbitts III tibbs@math.uh.edu wrote:
It seems your concern is the build flags, so why not just use %set_build_flags? %configure does that first, then goes through and modifies various autotools-related things and finally calls the configure script. It seems that nothing but %set_build_flags is relevant at all when autotools isn't in use.
Sort of a tangent, but I'm curious-- is this macro documented somewhere else in the guidelines? Is this a relatively new macro?
It is relatively new, yes:
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/fa08f0e5a18d27663084a...
Added 2 years ago.
On Tuesday, 27 August 2019 20:18:42 CEST Japheth Cleaver wrote:
I seem to recall discussion on this in the ancient past, but I couldn't find anything in the archive, nor on the current Fedora Packaging Guidelines docs.
There exist upstreams out there that are written in C/C++ but don't ship with a "configure" script. In some cases, I've seen this addressed by simply not running the %configure macro and then make-ing as normal, or by manually using %optflags somewhere. This is the suggestion in some tutorials for addressing this, e.g.: https://rpm-packaging-guide.github.io/#cello-working-with-spec-files
The %build section is where we tell the system how to actually build the software we are packaging. Since wrote a simple Makefile for our C implementation, we can simply use the GNU make command provided by rpmdev-newspec. However, we need to remove the call to %configure because we did not provide a configure script
I'd like to propose the addition of a "Configuration" section in the FPG (probably right under https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler ) that addresses the importance of using %configure. It ensures flags are properly exported into the environment, but could also do other arbitrary, distro-dependent things at some point, so it's still better to run the macro than not. There are two possible workarounds, depending on the whether %_configure (with underscore) is available, or if more control is needed for simulating a script.
Safer:
%build # source has no configure script; use macro anyway echo "#!/bin/sh" > configure ; chmod +x configure %configure make %{?_smp_mflags}
Recent versions; simple case:
%build # source has no configure script; use macro anyway %define _configure /bin/true %configure make %{?_smp_mflags}
I submitted https://github.com/redhat-developer/rpm-packaging-guide/issues/75 for that doc, but it seems like something about whether/how to work around this should be in these guidelines too, since they're used so much as a general reference.
Regards, -jc
In that case I would use %set_build_flags while making sure the Makefile respect CFLAGS and LDFLAGS, patching it if not.
* Japheth Cleaver:
I seem to recall discussion on this in the ancient past, but I couldn't find anything in the archive, nor on the current Fedora Packaging Guidelines docs.
The documentation for the Fedora build macros is here:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md
I wasn't able to get the Package Guidelines updated. Even the request to add a link is still open:
https://pagure.io/packaging-committee/issue/743
I'm sorry to say that I've given up on this long ago.
Thanks, Florian
packaging@lists.fedoraproject.org