RE: PTHREAD_CFLAGS provided by AX_PTHREAD where best to be attached?

[Dudziak Krzysztof]

Actually question asked initially here does not seem to exist as preprocessing 
then compilation is one single step. Both ...CFLAGS and ...CPPFLAGS should go 
to that building stage.
Eventually the order matters, i.e. their's placement in gcc command line string.

Question asked initially might exist if to replace ax_pthread-generated 
variables with gcc's -pthread option as question's objective.
gcc's manual describes it as gcc process driver's option. Latter one translates 
it and passes it to preprocessor, compiler and linker flags.
But how to use -pthread in Makefile.am if makefile carries out building in two 
steps, compilation then linking (with libtool in between
which possibly is irrelevant here)?
I believe automake-generated makefile by default work that way.

krzysiek

-----Original Message-----
From: Bob Friesenhahn [mailto:address@hidden
Sent: Thursday, 12. July 2018 20:28
To: Dudziak Krzysztof <address@hidden>
Cc: address@hidden
Subject: Re: PTHREAD_CFLAGS provided by AX_PTHREAD where best to be attached?

On Thu, 12 Jul 2018, Dudziak Krzysztof wrote:

> Hi,
> For makefiles which build piece of software in two separate steps:
> compilation then linking, will it be better to attach  PTHREAD_CFLAGS to 
> higher-level_CPPFLAGS than to higher-level_CFLAGS variable?
> Autotools along with libtool are used here, user-level variables (CFLAGS, 
> CPPFLAGS) are not manipulated through whole build chain.
> I can manipulate variables only at Makefile.am -level.

CPPFLAGS is for the pre-processor while CFLAGS is applied (as well as
CPPFLAGS) while compiling.  This means that putting the options in CFLAGS does 
work, although it would be better to deduce which options are for the 
pre-processor or the compiler and put them in the correct places.

> I learned gcc expects -pthread option which translates among others to
> some preprocessor define, therefore I wonder if it won't be better to
> attach PTHREAD_CFLAGS to higher-level_CPPFLAGS rather than to 
> higher-level_CFLAGS.

It should not work to put -pthread in CPPFLAGS since it is a compiler-driver 
option and not a pre-processor (e.g. /usr/bin/cpp) option.

Only, -I, -D, and -U type options (see the manual page for 'cpp') should be put 
in CPPFLAGS.

Bob
--
Bob Friesenhahn
address@hidden, 
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.simplesystems.org%2Fusers%2Fbfriesen%2F&amp;data=02%7C01%7CKrzysztof.Dudziak%40gemalto.com%7C2cfd69413ad6444ed36708d5e8254424%7C37d0a9db7c464096bfe31add5b495d6d%7C1%7C1%7C636670169138687886&amp;sdata=kqlLph71vuW%2BBZ0PKC5ew2Xb%2FFRRIIzTrCyMuvFU2Sk%3D&amp;reserved=0
GraphicsMagick Maintainer,    
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.GraphicsMagick.org%2F&amp;data=02%7C01%7CKrzysztof.Dudziak%40gemalto.com%7C2cfd69413ad6444ed36708d5e8254424%7C37d0a9db7c464096bfe31add5b495d6d%7C1%7C1%7C636670169138687886&amp;sdata=Fii3vstOw5Se1obwRwfN41COxKBnqZrNbpZ2aGl1e2o%3D&amp;reserved=0
________________________________
 This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.