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

[Satish Balay]

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
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
>