Comment 9 for bug 1010865

On 06/11/2012 10:51 AM, Martin Sandve Alnæs wrote:
> On 11 June 2012 10:18, Johan Hake<email address hidden> wrote:
>> On 06/11/2012 09:52 AM, Martin Sandve Alnæs wrote:
>>> On 11 June 2012 09:40, Joachim Haga<email address hidden> wrote:
>>>>>
>>>>>> Next time I miss something (like min/max in this case), I'll just write
>>>>>> "std::max" instead of creating a bug report.
>>>>>
>>>>> We have intentionally not allowed this, as it will make the interface
>>>>> more busy. It might be a good idea though, but not fully convinced.
>>>>>
>>>>
>>>> No strong opinion. But if you want to be convinced: The complexity is
>>>> completely decided by the user. It will not become necessary or usual to
>>>> use namespace qualifiers. It just makes them work.
>>>
>>> I don't see any problem with this.
>>
>> Me neither, but I wonder if we should expand the functionality while at
>> it. For now there are only a few hard coded headers available for a
>> user,<cmath> and surprise surprise<complex>.
>>
>> Should we make it possible to link other external libraries or home
>> brewed for that case, to the generation of compiled expressions? This
>> particular feature has come up a couple of times, in particular request
>> for the different boost functions.
>>
>> To be able to make this as powerful as we need we could expose the
>> relevant instant.build kwargs:
>>
>> local_headers=[], system_headers=[],
>> include_dirs=['.'], library_dirs=[], libraries=[],
>>
>> to the Expression interface via:
>>
>> configure = dict(
>> local_headers=["my_special_func.h"],
>> system_headers=["some_system_header.h"],
>> include_dirs=["some_obscure_path"],
>> library_dirs=["my_library_path"],
>> libraries=["my_special_func"])
>>
>> Expression(somestr, configure=configure)
>>
>> Then the user need to provide any non system paths manually.
>>
>> Johan
>
> That would be nice. Can it be made working with full expression class
> code as well? E.g.
>
> e = Expression(cppcode="class MyExpr: public Expression {...};",
> configure=dict(...))

But of course!

Also FYI there is no need for a kwarg in Expression:

    cppcode=some_code

just pass some_code and you will be fine.

> An additional idea: if cppcode is a single line and
> matches "*.h", we can load cppcode from a file.
> Then we can edit the cppcode with proper editor language support...
>
> Third idea:
> e = Expression(cppfile="myexpr.h")
> // with myexpr.h containing both class and configuration in comment:
> /*
> configure = dict(
> local_headers=["my_special_func.h"],
> system_headers=["some_system_header.h"],
> include_dirs=["some_obscure_path"],
> library_dirs=["my_library_path"],
> libraries=["my_special_func"])
> */
> class MyExpr: public ...
> { ... };

Neat, but that was a heck of a lot of magic... And it needs some
thorough unit testing if implemented. We have to think about how to
implement this properly, as it need to work for the
compile_extension_module interface as well.

> This way
> - the cppfile can be a single parameter to any script

Which you also can do by:

    e = Expression(open("myexpr.h").read())

> - the python script is not polluted with C++ build info
> - the build configuration is coupled with the code it configures

Sounds attractive.

The other path would be to provide some automatic configuration, but I
think that would create a living hell for us. It is way easier to force
the user provide the configuration.

By any coincidence, have you generate some large Expression code lately?

Johan

>
> Martin
>