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

[Satish Balay]

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
- c types
- make variables [CC_LINKER_FLAGS, PETSC_ARCH etc]
- perhaps others - which I don't know.

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