[petsc-dev] Why is -I$PETSC_DIR/src/dm/mesh/sieve in CLINKER even when configured without Sieve?

[Satish Balay]

Perhaps you missed pulling BuildSystem?

I had to redo my change.

BTW: Zimbra is misbehaving so e-mail communcation can be slow..

Satish

changeset:   17345:f83afb5a2eff
tag:         tip
user:        Satish Balay <balay at mcs.anl.gov>
date:        Wed Oct 13 00:07:35 2010 -0500
files:       config/PETSc/Configure.py
description:
revert Barry's revert of my change. Here 'include,include' correspond
to -Ipath, -Mpath [i.e module-path]. Currenlty the PATHS are the same
- but compiler options could potentially be different. When they are
the same -I option - a single call with both (include,modinclude)
paths can weed out duplicates better. Eventually configure can better
support a separate PATH list for modpaths - and this call fixed
appropriately.


----- Original Message -----
From: "Barry Smith" <bsmith at mcs.anl.gov>
To: "For users of the development version of PETSc" <petsc-dev at mcs.anl.gov>
Sent: Tuesday, October 12, 2010 8:53:44 PM GMT -06:00 US/Canada Central
Subject: Re: [petsc-dev] Why is -I$PETSC_DIR/src/dm/mesh/sieve in CLINKER even when configured without Sieve?


  Part of one you pushed was gibberish and caused crases: (includes,includes) I had to change it to (includes) but I suspect you meant to have something about tostring for modules in there and accidently deleted it.

   Barry

On Oct 12, 2010, at 5:37 PM, Satish Balay wrote:

> Barry,
> 
> I pused some fixes - so you should pull before attempting more fixes
> to this code..
> 
> Satish
> 
> On Tue, 12 Oct 2010, Barry Smith wrote:
> 
>> 
>>  One of the reasons for the repetitive -I and -L stuff in PETSc make lines is that in conf/variables we constructed some variables by adding two variables together that each individually had duplicates eliminated but the result did not have duplicates eliminated.
>> 
>>  I have moved this concatenation of variables back to PETSc/Configure.py so that the duplicates can be eliminated. Specifically this basically means merging the PACKAGES_LIBS and PACKAGES_INCLUDES with the basic libs and and includes before dumping to the conf/variables file
>> 
>>  As always there are likely to be problems crop up with some cases, maybe with shared libraries, with --prefix builds etc. Please report problems to petsc-maint at mcs.anl.gov
>> 
>> 
>>  Barry
>> 
>> More cleanup could be done to eliminate information on individual packages from going into petscvariables etc
>> 
>> 
>> On Oct 12, 2010, at 1:18 PM, Jed Brown wrote:
>>> 
>>> 
>>>> On Oct 12, 2010 6:48 PM, "Satish Balay" <balay at mcs.anl.gov> wrote:
>>>> 
>>>> On Tue, 12 Oct 2010, Jed Brown wrote:
>>>> 
>>>>> This also isn't specific to me, every one of your configure.logs is equally
>>>>> relevant. I get Sat...
>>>> 
>>>> One more case: where one uses diferent version of gcc vs gfortran [or
>>>> g77] - or one of these are installed in a different location.
>>>> 
>>>> For eg: on Mac - gfortran paths are totally different than gcc paths.
>>>> 
>>>>> So unless someone writes a special case for matching vendors, these
>>>>> paths will always exist. ...
>>>> 
>>>> We've always maintained that one should configure/rebild after
>>>> changing any parameters. So compiler version upgrade is one
>>>> such. [yeah lot of changes usually work, but the ones that don't work
>>>> -generate petsc-maint requests. Also if this is truly an issue - then
>>>> I think the following [with the correct minima LIBS option] is a
>>>> workarround for such folks - so the situation isn't too bad..
>>>> 
>>>> '--with-clib-autodetect=0 --with-fortranlib-autodetect=0 --with-cxxlib-autodetect=0 LIBS=-lgfortran...
>>>> 
>>>> Satish
>>> 
>> 
>> 
>