rjjbyron at shaw.ca
Mon May 8 11:04:14 PDT 2006
>> - Zlib to defOpt_fPIC
>> - With the nice confirmation page, "zlib Zlib" isn't descriptive
>> - Showing the inheritance in the override readout is moreso
>> - Plus, if you have 5-10 packages that all need "-fPIC",
>> it wouldn't make sense to have 5-10 identical files for each
>> package or have such as "fooPkg Zlib" in the override file..
> Naming it defOpt_fPIC due that defOpt is at this moment the name for "-O3
> -pipe" mode. Maybe the defOpt file should be renamed to "O3-pipe"
I think that no matter what, there's going to be a naming issue.
If someone changes the default mode in the options, all the filenames
technically should be changed, and then the code inside them has to
CFLAGS_defOpt_fPIC --> CFLAGS_myOpt_fPIC
Note that it would have to be 'O3_pipe' not 'O3-pipe' because the hyphen
is an invalid variable name.
Also, the '_' would imply that there is an optimization appending 'pipe'
to the inherited 'O3'.
People still have to change all the filenames and variable names in the
Here, someone is saying, use myOpt as the default. In this case,
'defOpt' can be understood as 'the default optimization mode defined by
DEF_OPT_MODE'. It's intuitive enough.
What else would you call it to disambiguate though? default_fPIC,
defOptMode_fPIC, or simply _fPIC to imply that it's inheriting from the
default rather than a specific file?
All the changing filenames and variable names would be unexpected
though; the ability to choose your default is there for flexibility. As
I saw it, people would change the values in defOpt as they desired so
they would know what 'defOpt' is, and the '_*' are descriptive additions
that can be used by multiple packages.
Anyhow, this was just my thinking; I kinda like how it is, but it
doesn't really matter what things are called from a functional perspective.
Thanks again for all the work getting this stuff into jhalfs.
More information about the alfs-discuss