Modify

Opened 8 years ago

Last modified 5 years ago

#229 new enhancement

Using a nonexistent header file should lead to an error message

Reported by: Ian Hinder Owned by:
Priority: minor Milestone:
Component: Cactus Version:
Keywords: Cc:

Description

If I have the following in my interface.ccl,

USES INCLUDE: vectors.h

but no thorn in my thornlist provides this header file, there is no error at compile time. Further, if I #include this file in my source file, an empty file is included, which means that again I don't get an error. The first indication that something is wrong is that the contents of the header file are not available, which makes debugging the problem with the thornlist very confusing.

I propose that the CST should emit a fatal error if one of the thorns tries to use a header file which does not exist.

Attachments (0)

Change History (14)

comment:1 Changed 8 years ago by Erik Schnetter

This is actually a feature of the Cactus include file mechanism: Several thorns can contribute towards an include file, and it is not an error if no thorn provides anything. This allows thorns to provide optional capabilities.

One example is LoopControl, which provides a header file loopcontrol.h. This header file overwrites (improves upon) the looping constructs provided by the flesh (in cctk_Loop.h). Other thorns can include this file, independent of whether LoopControl is in the thorn list or not. This makes it possible to write thorns that use LoopControl, and which still work if LoopControl is not present.

The original motivation for this include mechanism was matter thorns, i.e. thorns contributing to Tmunu. A spacetime thorn could thus include matter terms via a header file, and would thus work independent of whether any matter thorns are present or not.

comment:2 Changed 8 years ago by Ian Hinder

As in Ticket #217, it would be nice if the default behaviour was more intuitive, and the functionality for allowing the file to be included even if it doesn't exist could be enabled by an additional keyword.

In any case, the behaviour should be documented in the user guide. I can add that documentation if we decide that we don't want to change things.

comment:3 Changed 8 years ago by Frank Löffler

It sounds like the thorn providing this header file should provide a Cactus capability which the other thorn which depends on that very header file then would require.

comment:4 Changed 8 years ago by Erik Schnetter

The thorn providing this header file does provide this capability. The thorn using this header file did not require this capability, and thus the error checking did not work out as expected.

comment:5 Changed 8 years ago by Ian Hinder

Is it necessary to require a particular capability in order to include a header file?

I thought that the two things were orthogonal. In fact, if it is possible for more than one active thorn to provide a header file, and only one thorn providing a given capability can be active at one time, it would not be possible to make the provision of a header file entail requirement of an associated capability. So the two concepts are distinct.

comment:6 Changed 8 years ago by Frank Löffler

It is not necessary to require a particular capability in order to include _some_ header file.

The Cactus-mechanism for header-files is more like 'I would like to include whatever other thorns provide under that header-name, if any.' This does not introduce a dependency of thorns.

This is not what you want in your case. In your case you want one particular header file: that of thorn LoopControl. There should not be another thorn providing this file, and for sure not multiple. You have to have LoopControl to have that file, thus the required dependency.

comment:7 Changed 8 years ago by Erik Schnetter

Thorn LoopControl is optional. It provides a header file loopcontrol.h that overrides some flesh macros with different, potentially more efficient ones. When writing a thorn, one does not want to decide whether LoopControl is present or not.

Thus LoopControl adds to the loopcontrol.h include file if present, and if not present, this include file is empty. Thorns can unconditionally include loopcontrol.h, as long as they declare "USES INCLUDE loopcontrol.h" in their interface.ccl

This is independent of capabilities. The optional capability is there to create the correct link order (and, in general, to tell Cactus about this direct dependency between the thorns), because the macros in LoopControl.h's loopcontrol.h call some functions defined in LoopControl.h.

comment:8 Changed 8 years ago by Frank Löffler

You are right: replace loopcontrol in my previous comment with vectors.

comment:9 Changed 8 years ago by Frank Löffler

Can we close this ticket?

comment:10 Changed 8 years ago by Ian Hinder

Priority: majorminor
Type: defectenhancement

Let's ignore LoopControl now, as that was not the thorn that I had the problem with. I was using the Vectors thorn, and in my thorn I asked for the vectors.h header file. The thorn Vectors was not in my thorn list.

The correct thing to do if you want to use Vectors is to "require" the Vectors capability. If I had done that, I would have gotten a fatal error that there was no thorn providing that capability, which would have directed me to the solution of the problem (to include Vectors in my thornlist).

Instead, I simply asked for the header file, and the Cactus header file mechanism gives you an empty header file if no thorn provides one. My point is that this is counterintuitive. I would like for Cactus to give an error if you ask for a header file which does not exist. In order to support the case that this might be a valid situation, thorns could specify

OPTIONALLY USES INCLUDE: vectors.h

if it can deal with the header file being empty.

comment:11 Changed 8 years ago by Erik Schnetter

The "uses include" and "uses include header" mechanism was designed to combine multiple files into one. For example, Cactus makes copies of these files, and there is no error when two thorns provide the same header file -- they are concatenated. This is also probably something that few people expect.

I want to argue that this mechanism is not what we want to use here at all. Instead, thorn Vectors should set up the include path so that the header files it provides are found by other thorns. Other thorns then say "#include <...>", and if the include file is not found, it is clear what is going wrong -- the include path is not set correctly, which is something every C programmer is familiar with.

comment:12 Changed 8 years ago by Ian Hinder

Perhaps, but if you agree that the behaviour of the Cactus include mechanism is confusing, do you agree that it could be modified to make it less so in the way I suggested?

comment:13 Changed 8 years ago by Erik Schnetter

The Cactus include mechanism was designed to allow inlining across multiple thorns, in particular to allow inlining the calculation of Tmunu. Given that running without hydro is not an uncommon case, what you propose isn't just a small change, it requires rethinking the whole concept.

For example, multiple thorns can contribute code towards an include file. What do you suggest should happen in this case? Would you find it surprising if two thorns provided different code for the same include file?

comment:14 Changed 5 years ago by Frank Löffler

I agree with Erik, that we don't really need a new mechanism. We already have two, and the only important part is to 'teach' users to use the one they need, because otherwise unsurprisingly they don't get what they think they do.

Concerning this ticket: should we keep it open? Should we instead discuss this on the mailing list?

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from (none) to the specified user.
Next status will be 'confirmed'.
The owner will be changed from (none) to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.