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