[Users] Optional capabilities
Erik Schnetter
schnetter at cct.lsu.edu
Tue Nov 30 11:29:42 CST 2010
On Tue, Nov 30, 2010 at 12:01 PM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>
> On 30 Nov 2010, at 02:24, Erik Schnetter wrote:
>
>>> 1. Do we want all capabilities to generate automatically a preprocessor macro which can be checked? e.g. HAVE_CAPABILITY_HDF5, (to avoid conflicts with autoconf-generated macros)
>>
>> Yes, this should be the case.
>>
>>> 2. If not, then we could add the BEGIN_DEFINE...END_DEFINE lines above to HDF5.sh to manually set the define.
>>
>> I don't mind whether it is automatic or whether the scripts provide this.
>
> It is easy to add to the script, so I vote for it being automatic.
>
>>> 3. I think line 166 of CreateConfigurationBindings.pl should be removed.
>>
>> Could be -- do you want to post a patch? Or is this the line that
>> needs to be corrected to generate the #defines automatically?
>
> It could be modified to do that, or the required line could be added to the header file of the providing thorn. I think it is more natural to do the latter, since then it would only be added in one place rather than in each thorn that requires the capability.
>
> I attach a patch which:
>
> * Adds a line such as
>
> #define HAVE_CAPABILITY_<cap> 1
>
> where <cap> is the capability name, to the Capabilities/cctki_<cap>.h file. This is the file that is later included by any thorns which require the capability.
>
> * Removes the incorrect line which breaks compilation of cctki_Capabilities.h and does not do what looks like was intended.
>
>>> 4. There should be some mechanism for each thorn to include cctki_Capabilities.h automatically.
>>
>> Yes, definitely. It should probably be part of cctk.h.
>
>
> I'm not sure about the Cactus conventions for this. There aren't any other cctki_ headers included from cctk.h. The problem with including cctki_Capabilities.h in cctk.h is that when this file is modified, for example when a thorn is added or removed, every source file in the configuration would need to be recompiled. One way around this would be to exclude cctki_Capabilities.h from all thorns' dependencies, as is done with cctk_Arguments.h. However, this would mean that when a new thorn providing a capability was added, the thorns requiring this capability would not be recompiled. My best solution would be to have something like
>
> #include "../Configuration/Thorns/cctki_" CCTK_THORNSTRING ".h"
>
> in cctk.h. However, I can't get this to work. String concatenation happens after preprocessing, and there is no preprocessor operator to concatenate two string literals (the ## operator only works on identifiers, not strings).
>
> The best solution I can get to work is to have all thorns which optionally require capabilities include their corresponding "../Configuration/Thorns/cctki_<thornname>.h" file manually.
I like the patch; please apply it. Do you want to extend it to also
auto-generate a makefile definition HAVE_CAPABILITY_XXX?
I think all we need is to rename cctki_Capabilities.h to
cctk_Capabilities.h, and protect it from make the same way
cctk_Arguments.h is protected. Then each thorn can include
<cctk_Capabilities.h>, and will then automatically include its own
capabilities file. Adding/removing thorns won't matter because the
file is protected. If a thorn is added that provides a new capability
that thorn T uses, then thorn T's file Thorns/cctki_T.h will be
modified, and make will recompile the thorn. (This is exactly the same
mechanism as for cctk_Arguments.h, and it works fine there.)
-erik
--
Erik Schnetter <schnetter at cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/
More information about the Users
mailing list