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

[Barry Smith]

On Jan 27, 2010, at 1:02 PM, 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. I know Barry hates  
> this. Do
> you hate it so bad that we should keep the switch?

    Of course we should keep the changes I made. Having a special case  
for types is totally unnecessary and adds complexity as a special  
case. Why add complexity, there is no gain except that we happened to  
do it that way before, which is not a good reason.

   Regarding void* -> void-p or void_p.   I think that Matt used  
void_p because that is common among c/c++ language processing people  
to get rid of the *. It could be void-pointer, voidpointer or voidp  
also. I don't care which is used.

    Barry


>
>   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
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
>
>
> -- 
> What most experimenters take for granted before they begin their  
> experiments is infinitely more interesting than any results to which  
> their experiments lead.
> -- Norbert Wiener