[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