[RFC] %configure macro when missing a ./configure script

[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.

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

[Jason L Tibbitts III]

> >>>> "JC" == Japheth Cleaver
> <cleaver(a)terabithia.org&gt; 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<

[Japheth Cleaver]

On 8/27/2019 11:30 AM, Jason L Tibbitts III wrote:
> >>>>> "JC" == Japheth Cleaver
> <cleaver(a)terabithia.org&gt; 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

[Jason L Tibbitts III]

> >>>> "JC" == Japheth Cleaver
> <cleaver(a)terabithia.org&gt; 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<

[Japheth Cleaver]

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

[Japheth Cleaver]

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

[Japheth Cleaver]

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

[Ben Rosser]

On Tue, Aug 27, 2019 at 2:31 PM Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; 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

[Jason L Tibbitts III]

> >>>> "BR" == Ben Rosser
> <rosser.bjr(a)gmail.com&gt; 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<

[Miro Hrončok]

On 27. 08. 19 21:10, Ben Rosser wrote:
>  On Tue, Aug 27, 2019 at 2:31 PM Jason L Tibbitts III
> <tibbs(a)math.uh.edu&gt; 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/fa08f0e5a18d276630...

Added 2 years ago.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Robert-André Mauchin]

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.

[Florian Weimer]

* 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/buildf...

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