[petsc-dev] CFLAGS and COPTFLAGS

Sean Farley sean.michael.farley at gmail.com
Sun Jan 19 18:31:12 CST 2014


bsmith at mcs.anl.gov writes:

> On Jan 19, 2014, at 5:50 PM, Jed Brown <jed at jedbrown.org> wrote:
>
>> Barry Smith <bsmith at mcs.anl.gov> writes:
>>>   User runs
>>> 
>>>     —with-cc=cc CFLAGS=“-m64” —with-debugging=0
>>> 
>>>   gets the same performance as
>>> 
>>>     —with-cc=cc CFLAGS=“-m64” —with-debugging=1
>>> 
>>>    Can’t understand why.
>> 
>> It wouldn't have quite the _same_ performance because of PETSc debugging
>> overhead, but point taken.  OTOH, we may be squashing optimization flags
>> internal to the wrappers
>
>    Nope because in my previous assignment I asked Satish to check for -O stuff in compiler wrappers as well as CFLAGS.
>
>> and some compilers have funny names for
>> optimization flags.
>
>    This is a small possibility because normally there is a -Od as well as the funny named other stuff. If we come upon another funny name that replaces -Od we can incorporate that as well.

I haven't chimed in for this thread but I'd like to point out that this
CFLAGS trickery is also a problem for package maintainers. These people
are usually admins and have no specific knowledge of PETSc
internals. Every single time a package does something outside the norm
for configure makes us curse. A lot.

For example, PETSc is the only project in all of 17963 ports of MacPorts
that doesn't accept CC, CXX, FC, etc. for changing its compiler for
configure. These types of variables are set outside of the port file
(i.e. in the base system of MacPorts) and make it annoying to deal with
PETSc.

Same goes for package layout. There are about 100 packages in MacPorts
that violate the standard layout of /include, /bin, /lib, etc. (this
means having a folder named 'conf' is not allowed). That's less than
1%. Each of these packages causes extra work for the maintainer and
makes us less likely to provide this package for other users.



More information about the petsc-dev mailing list