Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-07 Thread Richard W.M. Jones 
On Thu, Jan 05, 2017 at 11:58:07AM +0100, Michael Schwendt wrote:
> On Thu, 5 Jan 2017 00:58:00 +, Richard W.M. Jones wrote:
> 
> > It would also be nice if:
> > 
> >   PYTHON=/usr/bin/python3 %configure
> > 
> > didn't (silently) do the wrong thing by default.  For a long time we
> > shipped a nbdkit-python3 package which was using python2, and that was
> > found to be the cause.
> 
> And the configure script didn't accept the external definition of $PYTHON,
> I guess.

No, the ./configure script DOES accept $PYTHON if it is set in the
environment.  The problem happens in the expansion of the %configure
macro.  I am mainly pointing out this trap since I don't see a simple
fix.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-06 Thread Pavel Raiskup 
On Friday, January 6, 2017 3:24:46 PM CET Florian Weimer wrote:
> On 01/06/2017 03:20 PM, Pavel Raiskup wrote:
> > On Friday, January 6, 2017 3:02:22 PM CET Florian Weimer wrote:
> >>> Wouldn't it suffice to put PYTHON= at the end? autotools' configure
> >>> scripts accept such assignments (and even remember them in
> >>> config.status etc).
> >>
> >> Indeed, this looks like a reasonable solution.
> >
> > Is %configure only for auto-tooled configure?
> 
> Pretty much, the ./configure script must be sufficiently compatible.
> 
> > It could cause FTBFS otherwise.
> 
> It's something that has to be applied to the SPEC file anyway, so it's 
> not something that involves a global switch causing widespread breakage.

Sorry I should have catch this before -- sounds really reasonable.

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-06 Thread Florian Weimer 

On 01/06/2017 03:20 PM, Pavel Raiskup wrote:

On Friday, January 6, 2017 3:02:22 PM CET Florian Weimer wrote:

Wouldn't it suffice to put PYTHON= at the end? autotools' configure
scripts accept such assignments (and even remember them in
config.status etc).


Indeed, this looks like a reasonable solution.


Is %configure only for auto-tooled configure?


Pretty much, the ./configure script must be sufficiently compatible.


It could cause FTBFS otherwise.


It's something that has to be applied to the SPEC file anyway, so it's 
not something that involves a global switch causing widespread breakage.


Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-06 Thread Pavel Raiskup 
On Friday, January 6, 2017 3:02:22 PM CET Florian Weimer wrote:
> > Wouldn't it suffice to put PYTHON= at the end? autotools' configure
> > scripts accept such assignments (and even remember them in
> > config.status etc).
> 
> Indeed, this looks like a reasonable solution.

Is %configure only for auto-tooled configure?  It could cause FTBFS otherwise.

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-06 Thread Florian Weimer 

On 01/06/2017 01:59 PM, Thomas Moschny wrote:

2017-01-05 14:01 GMT+01:00 Florian Weimer :

On 01/05/2017 11:58 AM, Michael Schwendt wrote:


On Thu, 5 Jan 2017 00:58:00 +, Richard W.M. Jones wrote:


It would also be nice if:

  PYTHON=/usr/bin/python3 %configure

didn't (silently) do the wrong thing by default.  For a long time we
shipped a nbdkit-python3 package which was using python2, and that was
found to be the cause.



And the configure script didn't accept the external definition of $PYTHON,
I guess. What could the %configure macro do about it?
If you look at "rpm -E %configure", anything it does wouldn't help, if
the parameters are ignore or don't make it into the Makefiles.



I suspect the problem is that the PYTHON=… setting is only applied to the
first shell command in the %configure expansion.  It's not the configure
invocation, just a plain variable assignment, so PYTHON is set, but not
exported to subprocesses (such as the future invocation of ./configure).

There is probably some shell hackery we could use to avoid that, but I don't
think more magic should be the goal.


Wouldn't it suffice to put PYTHON= at the end? autotools' configure
scripts accept such assignments (and even remember them in
config.status etc).


Indeed, this looks like a reasonable solution.

Thanks,
Florian


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-06 Thread Thomas Moschny 
2017-01-05 14:01 GMT+01:00 Florian Weimer :
> On 01/05/2017 11:58 AM, Michael Schwendt wrote:
>>
>> On Thu, 5 Jan 2017 00:58:00 +, Richard W.M. Jones wrote:
>>
>>> It would also be nice if:
>>>
>>>   PYTHON=/usr/bin/python3 %configure
>>>
>>> didn't (silently) do the wrong thing by default.  For a long time we
>>> shipped a nbdkit-python3 package which was using python2, and that was
>>> found to be the cause.
>>
>>
>> And the configure script didn't accept the external definition of $PYTHON,
>> I guess. What could the %configure macro do about it?
>> If you look at "rpm -E %configure", anything it does wouldn't help, if
>> the parameters are ignore or don't make it into the Makefiles.
>
>
> I suspect the problem is that the PYTHON=… setting is only applied to the
> first shell command in the %configure expansion.  It's not the configure
> invocation, just a plain variable assignment, so PYTHON is set, but not
> exported to subprocesses (such as the future invocation of ./configure).
>
> There is probably some shell hackery we could use to avoid that, but I don't
> think more magic should be the goal.

Wouldn't it suffice to put PYTHON= at the end? autotools' configure
scripts accept such assignments (and even remember them in
config.status etc).

- Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-05 Thread Florian Weimer 

On 01/05/2017 11:58 AM, Michael Schwendt wrote:

On Thu, 5 Jan 2017 00:58:00 +, Richard W.M. Jones wrote:


It would also be nice if:

  PYTHON=/usr/bin/python3 %configure

didn't (silently) do the wrong thing by default.  For a long time we
shipped a nbdkit-python3 package which was using python2, and that was
found to be the cause.


And the configure script didn't accept the external definition of $PYTHON,
I guess. What could the %configure macro do about it?
If you look at "rpm -E %configure", anything it does wouldn't help, if
the parameters are ignore or don't make it into the Makefiles.


I suspect the problem is that the PYTHON=… setting is only applied to 
the first shell command in the %configure expansion.  It's not the 
configure invocation, just a plain variable assignment, so PYTHON is 
set, but not exported to subprocesses (such as the future invocation of 
./configure).


There is probably some shell hackery we could use to avoid that, but I 
don't think more magic should be the goal.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-05 Thread Michael Schwendt 
On Thu, 5 Jan 2017 00:58:00 +, Richard W.M. Jones wrote:

> It would also be nice if:
> 
>   PYTHON=/usr/bin/python3 %configure
> 
> didn't (silently) do the wrong thing by default.  For a long time we
> shipped a nbdkit-python3 package which was using python2, and that was
> found to be the cause.

And the configure script didn't accept the external definition of $PYTHON,
I guess. What could the %configure macro do about it?
If you look at "rpm -E %configure", anything it does wouldn't help, if
the parameters are ignore or don't make it into the Makefiles.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-04 Thread Richard W.M. Jones 
On Mon, Jan 02, 2017 at 03:10:26PM +0100, Pavel Raiskup wrote:
> On Monday, January 2, 2017 10:56:10 AM CET Florian Weimer wrote:
> > The final values of CFLAGS/LDFLAGS/… are set (as shell variables) by the 
> > %configure macro.  There is no other immediately obvious way to get 
> > those definitions.  This means that if you can't use %configure for some 
> > reason, you are out of luck.
> > 
> > In this situation, this still works:
> > 
> > %global %_configure :
> > %configure
> > 
> > As a result, %configure tries to run “:” instead of “./configure”, which 
> > is a NOP, and only the shell variable initialization remains.
> > 
> > Is this the recommend way to initialize the compiler flags?
> 
> Meh, it would be hard to believe this is prefered way... at least because 
> there
> are default options like --prefix=/usr in %configure.
> 
> > Should we introduce a %setup_cflags macro to make this more explicit?
> 
> Maybe.
> 
> Also I'd like to se the %configure macro more "modularized", because it does 
> too
> much ATM and as you said, %configure is not for everybody.  So one could call
> something like:
> 
> %configure_libtool_hacks
> %configure_fix_gnuconfig
> 
> .. only when there are reasons to not call %configure directly.

It would also be nice if:

  PYTHON=/usr/bin/python3 %configure

didn't (silently) do the wrong thing by default.  For a long time we
shipped a nbdkit-python3 package which was using python2, and that was
found to be the cause.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-02 Thread Michael Schwendt 
On Mon, 02 Jan 2017 15:10:26 +0100, Pavel Raiskup wrote:

> > 
> > %global %_configure :
> > %configure
> > 
> > As a result, %configure tries to run “:” instead of “./configure”, which 
> > is a NOP, and only the shell variable initialization remains.
> > 
> > Is this the recommend way to initialize the compiler flags?  
> 
> Meh, it would be hard to believe this is prefered way... at least because 
> there
> are default options like --prefix=/usr in %configure.

Note that

  %configure || :

is something some reviewers have been recommending for some time,
because it is a cheap and very convenient way to get the env definitions
and exports. The parameters passed to the configure script are irrelevant
when there is no configure script.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-02 Thread Pavel Raiskup 
On Monday, January 2, 2017 10:56:10 AM CET Florian Weimer wrote:
> The final values of CFLAGS/LDFLAGS/… are set (as shell variables) by the 
> %configure macro.  There is no other immediately obvious way to get 
> those definitions.  This means that if you can't use %configure for some 
> reason, you are out of luck.
> 
> In this situation, this still works:
> 
> %global %_configure :
> %configure
> 
> As a result, %configure tries to run “:” instead of “./configure”, which 
> is a NOP, and only the shell variable initialization remains.
> 
> Is this the recommend way to initialize the compiler flags?

Meh, it would be hard to believe this is prefered way... at least because there
are default options like --prefix=/usr in %configure.

> Should we introduce a %setup_cflags macro to make this more explicit?

Maybe.

Also I'd like to se the %configure macro more "modularized", because it does too
much ATM and as you said, %configure is not for everybody.  So one could call
something like:

%configure_libtool_hacks
%configure_fix_gnuconfig

.. only when there are reasons to not call %configure directly.

Pavel


> Thanks,
> Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-02 Thread Igor Gnatenko 
On Mon, Jan 2, 2017 at 10:56 AM, Florian Weimer  wrote:
> The final values of CFLAGS/LDFLAGS/… are set (as shell variables) by the
> %configure macro.  There is no other immediately obvious way to get those
> definitions.  This means that if you can't use %configure for some reason,
> you are out of luck.
>
> In this situation, this still works:
>
> %global %_configure :
> %configure
>
> As a result, %configure tries to run “:” instead of “./configure”, which is
> a NOP, and only the shell variable initialization remains.
>
> Is this the recommend way to initialize the compiler flags?
export CFLAGS="%{__global_cflags}"
export CXXFLAGS="%{__global_cxxflags}"
export LDFLAGS="%{__global_ldflags}"
and others (e.g. fortran flags)

It's not really portable way (it most likely will not work on other
RPM-based distros, but who cares). RPM itself define only %optflags.
export CFLAGS="${CFLAGS:-%__global_cflags}"
export CXXFLAGS="${CXXFLAGS:-%__global_cxxflags}"
export FFLAGS="${FFLAGS:-%__global_fflags}"
export FCFLAGS="${FCFLAGS:-%__global_fcflags}"
export LDFLAGS="${LDFLAGS:-%__global_ldflags}"
>
> Should we introduce a %setup_cflags macro to make this more explicit?
Would be helpful to not copy-paste exports over buildsystems.
>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Best practices for getting CFLAGS/LDFLAGS etc.

2017-01-02 Thread Florian Weimer 
The final values of CFLAGS/LDFLAGS/… are set (as shell variables) by the 
%configure macro.  There is no other immediately obvious way to get 
those definitions.  This means that if you can't use %configure for some 
reason, you are out of luck.


In this situation, this still works:

%global %_configure :
%configure

As a result, %configure tries to run “:” instead of “./configure”, which 
is a NOP, and only the shell variable initialization remains.


Is this the recommend way to initialize the compiler flags?

Should we introduce a %setup_cflags macro to make this more explicit?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org