[petsc-dev] Petsc-dev compilation: error because of underscore.

[Barry Smith]

On Jan 27, 2010, at 1:43 PM, Satish Balay wrote:

> On Wed, 27 Jan 2010, Matthew Knepley wrote:
>
>> So what, at the end of the day, do we want. I was fine with making
>> most things '-' and keeping '_' for types and uppercase crap.
>
> My view is: configure uses '-' for space - except for predefined
> names.
>
> - package names

       Where is this? We should fix it. SuperLU_DIST name is  
SuperLU_Dist that is why there is an underscore, not because it is a  
space replaced with an _

> - c types

      Why? Just to make life more complicated?

> - make variables [CC_LINKER_FLAGS, PETSC_ARCH etc]

     I think we are stuck with this because it is the autoconf way.  
Maybe we could support both with these :-).

> - perhaps others - which I don't know.

    Why should there be others that people have to know about and deal  
with? Life is already way to stinking hard, why make it harder?

    Ok enough wasted bandwidth on this topic, lets find something more  
interesting to argue about.


    Barry

>
> etc. And its ok to have 'c types' have its own consistant notation [if
> possible].
>
> Satish
>
>> I know Barry hates this.  Do you hate it so bad that we should keep
>> the switch?
>
>>
>>  Matt
>>
>> On Wed, Jan 27, 2010 at 12:23 PM, Satish Balay <balay at mcs.anl.gov>  
>> wrote:
>>
>>> I guess I need to bite this one.  I think this backlash against  
>>> folks
>>> confusing '-' with '_' is causing bad design [aka avoid '_' at all
>>> costs in configure]
>>>
>>> To me having 'void-p' and 'size_t' is inconsistant. And causes more
>>> confusion.
>>>
>>> Yeah - for configure options we have a notation of hiphen separated
>>> words. But those rules doesn't modify datatypes, package names.
>>>
>>> But for datatypes - we have underscore notation which is usually
>>> consistant - as most [but not all] c datatypes use '_' notation.
>>>
>>> so - converting 'long long' to 'long_long' is consistant to me.
>>>
>>> Wrt 'void_p' the correct datatype is 'void*' Since we didn't know  
>>> how
>>> to represent it properly - we created a type void_p [similar to  
>>> other
>>> c types with '_', but this type is used primarily in configure].
>>>
>>> So currently we are applying the autoconf 'space' rule to 'void p'
>>> type which is a bogus intermediate represantation. Hypinated types  
>>> are
>>> more consistant to me.
>>>
>>> Satish
>>>
>>> On Tue, 26 Jan 2010, Barry Smith wrote:
>>>
>>>>
>>>> On Jan 26, 2010, at 6:41 PM, Satish Balay wrote:
>>>>
>>>>> The following change gets configure going.
>>>>>
>>>>> But I think Barry is looking at a different fix.. [if not - I  
>>>>> can push
>>> this]
>>>>
>>>>  DAMN STRAIGHT I AM looking for something different. I am looking  
>>>> for
>>> the
>>>> correct fix, not some ugly crap hack and terrible inconsistent user
>>> interface!
>>>>
>>>>  Here is the issue: When providing an option (not capitalized,  
>>>> like the
>>>> autoconf style "environmental variables" AR_FLAGS), for example
>>> --with-batch,
>>>> how does one represent SPACES in the option name. We chose  
>>>> (actually Matt
>>>> chose) to represent it with a -
>>>>
>>>>  Because of "how the python code happened to be written" this  
>>>> rule was
>>>> violated with the options --with-sizeof_int --with-sizeof_long_long
>>>> --with-sizeof_void_p. It was not violated for a good user interface
>>> reason but
>>>> simply because Matt happened to write the code that generated the  
>>>> strings
>>> this
>>>> way.
>>>>
>>>>  When I discovered this inconsistent (for no reason) usage I  
>>>> tried to
>>> fix it.
>>>> I fixed the _ after sizeof_ and partially fixed the _ in the  
>>>> other blank
>>> but
>>>> missed its generation with the batch command. This is why things  
>>>> broke
>>> with
>>>> with the --with-batch option.
>>>>
>>>>  I have tried to fixed this again by removing these invalid  
>>>> "exceptions"
>>> from
>>>> petsc-dev and handling the " " correctly in BuildSystem; so  
>>>> everyone
>>> please hg
>>>> update BOTH! Please let me know if something is still broken so I  
>>>> can fix
>>> it.
>>>>
>>>> Why do I make such a big deal about this? If the rule is ALWAYS  
>>>> replace
>>> " "
>>>> in option strings with - this is easy to remember and use. If the  
>>>> rule is
>>>> almost always replace " " with - except in a few special cases  
>>>> that you
>>> just
>>>> have to happen to know, this is an insane rule.
>>>>
>>>>  Barry
>>>>
>>>> Notes: one could argue that to be consistent with the  
>>>> CAPS_OPTIONS we
>>> should
>>>> always use _ even in the --with_xx options. This is inconsistent  
>>>> with
>>> autoconf
>>>> that uses --with-xx so which consistency should we match? I find  
>>>> the -
>>> more
>>>> attractive and dislike the CAPS_OPTIONS so am happy with the way  
>>>> it is,
>>> but am
>>>> open to changing it.
>>>>
>>>> What about --with-sizeof-size_t, how come that has an underscore?  
>>>> It has
>>> an
>>>> underscore because the type name has an underscore, it does not  
>>>> come from
>>>> applying a replace " " with _.
>>>>
>>>>
>>>>>
>>>>> Satish
>>>>>
>>>>> -      for exc in ['superlu_dist', 'PETSC_ARCH', 'PETSC_DIR',
>>>>> 'CXX_CXXFLAGS', 'LD_SHARED', 'CC_LINKER_FLAGS',  
>>>>> 'CXX_LINKER_FLAGS',
>>>>> 'FC_LINKER_FLAGS', 'AR_FLAGS', 'C_VERSION', 'CXX_VERSION',
>>>>> 'FC_VERSION','qd_dd', 'void_p']:
>>>>> +      for exc in ['superlu_dist', 'PETSC_ARCH', 'PETSC_DIR',
>>>>> 'CXX_CXXFLAGS', 'LD_SHARED', 'CC_LINKER_FLAGS',  
>>>>> 'CXX_LINKER_FLAGS',
>>>>> 'FC_LINKER_FLAGS', 'AR_FLAGS', 'C_VERSION', 'CXX_VERSION',
>>>>> 'FC_VERSION','qd_dd',
>>>>> 'known-sizeof-void_p','known-sizeof-long_long','known-sizeof- 
>>>>> size_t']:
>>>>>
>>>>>
>>>>> On Tue, 26 Jan 2010, Matthew Knepley wrote:
>>>>>
>>>>>> Ah, will you make a list or should i?
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>>> All can run with '--with-batch=1' on their machines to reproduce
>>> the
>>>>>>> problem. [and see if their fixes fix it or not]
>>>>>>>
>>>>>>> Satish
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>