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