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