[petsc-dev] [petsc-maint #49590] problem building petsc-dev

[Satish Balay]

On Fri, 16 Jul 2010, Barry Smith wrote:

>  Hmm, maybe we should just require users to use --with-pic if they
>    want to do shared libraries.

This is pushing the burden of configure internal dependencies on to
users [i.e just so that configure can give an error message for usage
'--with-pic=0 --with-shared=1' - one has to always know and use
--with-pic correctly]. 

>    The other choice is to remove --with-pic completely and
> automatically look for pic flags ONLY if --with-shared is turned on?
> Both match our standards; BUT --with-pic is a pain to always have to
> type in and it would be rare that one wants --with-pic but not
> --with-shared

This usage is valid. Alternative way to achieve --with-pic=1 is:
'CFLAGS=-fPIC FFLAGS=-fPIC'. Howeve checkPIC() is a bit ad-hoc - and I
think we had some issues when it was switched-on all the time. [some
of the stablization of this code hinges on checking the pic-option
varaiants in the correct order - or there is breakage with some
compilers]

Perhaps this is ok. I'm still inclined towards yesterday's behavior
though.

One more senario: introduce a new type of option: nargs.ArgUnitary -
i.e somethig that has a single state. [nargs.ArgBool has 2 states - so
such options are to be supported for both states 0/1 or true/false]

for single-state options - there is no flip-side. Configure can do
whatever it wants - but the user can force only one state. This is
ideal for say '--force-pic'.

Maybe this is complicating things too much.. [trying to create a
unitary option for something that functionally looks like bolean]

Satish


> 
>    Barry
> 
> On Jul 16, 2010, at 9:09 PM, Satish Balay wrote:
> 
> > The previous change to pic default had this comment. [And this change
> > must have been done form some other petsc-maint issue. And I keep
> > forgetting senarios/issues when this was done]
> > 
> >>>>>> 
> > 5a0c830b3a17
> >    -defaut pic=0 [shared=0]
> >    - do pic check only when shared=1 or pic=1
> >    - special pic check for borland is removed - as its no longer required for shared=0 [default]
> > <<<<<
> > 
> > So the primary issue with default-pic=1 is: its contradictary to
> > default-shared=0. [and will be tempted to rectify this contradiction a
> > couple of years from now again]
> > 
> > Satish
> > 
> > On Fri, 16 Jul 2010, Barry Smith wrote:
> > 
> >> 
> >>  Hmmm, I never use --with-pic=1 
> >> 
> >>  Why don't we just enable pic by default. Then if user does --with-pic=0 --with-shared we complain. Better than always required shared people to use --with-pic. People who don't want to use --with-pic are far and few between.
> > 
> > 
> >> 
> >>    Barry
> >> 
> >> On Jul 16, 2010, at 8:39 PM, Satish Balay wrote:
> >> 
> >>> On Fri, 16 Jul 2010, Barry Smith wrote:
> >>> 
> >>>> 
> >>>> I think Satish is right we should have
> >>>> 
> >>>> --with-shared-libraries
> >>>> --with-dynamic-loading 
> >>>> 
> >>>> I haven't made this change but I've changed
> >>>> 
> >>>> improved help message for --with-shared	and --with-dynamic
> >>>> made --with-dynamic require --with-shared
> >>>> make --with-shared NOT allow --with-pic=0
> >>> 
> >>> Barry,
> >>> 
> >>> With this change one has to always do the following for sharedlibs:
> >>> 
> >>> --with-pic=1 --with-shared=1
> >>> 
> >>> and for dynamic libraries.
> >>> 
> >>> --with-pic=1 --with-shared=1 --with-dynamic=1
> >>> 
> >>> Earlier behavior was for --with-pic to be implicitly enabled for
> >>> with-shared or with-dynamic. It would be good to retain the old
> >>> behavior.
> >>> 
> >>> Part of the problem is: configure cannot distinguish between user
> >>> provided value vs configure default value - for any given option. So
> >>> we can't do both:
> >>> 
> >>> * default-pic=disabled but  autoenable if  user provides --with-shared=1
> >>> * if user provides '--with-pic=0 --with-shared=1' - flag as error.
> >>> 
> >>> [I didn't remember this part - when I started this thread about this
> >>> issue. Looks like we should silently ignore --with-pic - when
> >>> --with-shared is enabled]
> >>> 
> >>> Satish
> >>> 
> >>> 
> >>>> I'll change the option names in a little while
> >> 
> >> 
> > 
> 
>