[Users] Optional capabilities
Ian Hinder
ian.hinder at aei.mpg.de
Tue Nov 30 14:19:23 CST 2010
On 30 Nov 2010, at 18:29, Erik Schnetter wrote:
> 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.
I don't have commit rights to the Cactus flesh. I'm going to modify the patch anyway, so please don't commit it just yet.
> Do you want to extend it to also
> auto-generate a makefile definition HAVE_CAPABILITY_XXX?
Good idea. I had thought this was there already, but now I realise that this is done manually in the HDF5.sh script. I will modify the patch so that we have both makefile definitions and preprocessor macros definitions.
> 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.)
Of course! I was confused about this, but you're right, it should work OK that way. Given that it is safe for all thorns to include cctk_Capabilities.h, should we just include it in cctk.h for all thorns?
--
Ian Hinder
ian.hinder at aei.mpg.de
More information about the Users
mailing list