Fernando Perez wrote:
> On Dec 4, 2007 1:24 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>> Fernando Perez wrote:
>
>>> Is this something that really needs to be a code package? Why can't
>>> this knowledge (or at least the easily overridable part of it) be
>>> packaged in one or more .conf/.ini plaintext files? In that way,
>>> users could easily grab new data files or tweak the builtin ones, and
>>> at build time say
>>>
>>> setup.py install --compiler_conf=~/my_tweaked.conf
>>>
>>> Is that impossible/unreasonable for some reason?
>> It's not impossible, but there are at least a couple of places where it
>> might be
>> unreasonable. For example, look at the get_flags_arch() for Intel compilers:
>
> [...]
>
> I see. How about an alternate approach: exposing a simple api and
> allowing users to declare a *python* file to execfile() at load time
> looking for the config?
>
> Something like:
>
> setup.py install --compiler_conf=~/my_tweaked_config.py
>
> where the config file would be (sketch, not real code here):
>
> def make_flags(compiler, etc...):
> flags = []
> ....
> return flags
>
> There could be a simple API for what functions the config file (down
> to their names and signatures) can declare, and if any of them are
> declared, they get called and their output is used. They get fed the
> default state of the same variables, so that they can choose to modify
> or outright replace them based on the user's need.
>
> The config code would then
>
> user_ns = {}
> execfile(user_config_filename,user_ns)
> for name,val in user_ns.items():
> if name in approved_functions and callable(val):
> flags[name] = val(*approved_functions[name].default_args)
>
>
>
> What say you?
Well, like I said, for tweaking, a simple data file works better than code.
There's no need to do all of those "if" tests since I know what platform I'm on.
We should definitely have a simple data file that we can read flags from. It's
just the general case that requires code.
One thing in favor of numpy_fcompilers is that we can ship the updates to the
general case more frequently. This means that other packages using Fortran (but
not tied to a particular platform) can ship the updated code instead of telling
all of their users to read their Fortran compiler manuals or ask on the mailing
list for the correct settings to work around our old defects.
Tweaking should be the province of the developer and the desperate. We have to
be able to tweak, but we should spend more time on preventing the need for
tweaking.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
