files and cmake-include target properties

[lhstrh]

There current are some inconsistencies between the C and Cpp target when it comes to the handling of the files cmake-include target properties. Let me summarize my understanding (please provide corrections where necessary):

• C performs a search to find the files listed in the files property and copies them to src-gen
• Cpp ignores files
• C treats cmake-include entries the same way it treats files, meaning it will copy them into src-gen
• Cpp takes a different approach and runs cmake in the src directory, meaning it requires no copying but lets the user specify (relative) paths to resources needed for compilation

Open Questions

(please edit this post to add viewpoints)

Should we use files?

Pros

• generated sources are self-contained, can be shipped and built independently

Cons

• redundancy

Should cmake files use relative paths?

Pros

• simplicity

Cons

• a general lookup/copy mechanism such as used for files is more flexible

How should we deal with target properties in imported files?

• a related question pertains to preambles (see Should the preambles of an unsued import become visible? #516)

Currently (after merging cmake-include-improvements to master), the C target will copy the files listed in the files and cmake-include target properties of imported .lf files into the src-gen directory of the main .lf file. The pros and cons are very similar to above:

Pros

• Generated sources are self-contained, can be shipped and built independently
• Less clutter in the main .lf file as we don't have to repeat the files and cmake-include target properties
• More or less automatic resolving of dependencies of imported .lf files.

Cons

• Redundancy due to copying files and creating duplicates of the original.

[cmnrd]

I am not sure what precisely is meant by 'redundancy' in the cons list of the Files property, but I suppose it is redundancy in the file system. I would like to add to this that there is redundancy in the way we keep track of dependencies. Let's say that we write an LF file that requires some additional logic that is implemented in complementary C/C++ source and header files. With the current C++ behavior, all that we need to do is create a cmake include file that adds the additional sources to the target and makes the header files available on the included paths. In other words: cmake is already managing the dependencies on additional C/C++ files for us. Now with the C behavior, we have to additionally list every single file in files to ensure that it's copied. So we have two lists of additional files in two different places.

I don't quite understand the points under "Should cmake files use relative paths?". I think yes they should! But I don't understand how this relates to copying. Maybe someone can shed some light?

I also don't understand the Cons of "How should we deal with target properties in imported files?". As far as I see, merging the cmake-includes of imported files would also work if the cmake files are resolved directly in the source directory. I don't understand why this would require copying.

I think another important point to mention in this discussion is the one made here. If we rely on lfc to build federates on host machines, then we don't need to worry about the structure of the src-gen directory at all, since all we need to ship is the src directory.

[Soroosh129]

I am not sure what precisely is meant by 'redundancy' in the cons list of the Files property, but I suppose it is redundancy in the file system. I would like to add to this that there is redundancy in the way we keep track of dependencies. Let's say that we write an LF file that requires some additional logic that is implemented in complementary C/C++ source and header files. With the current C++ behavior, all that we need to do is create a cmake include file that adds the additional sources to the target and makes the header files available on the included paths. In other words: cmake is already managing the dependencies on additional C/C++ files for us. Now with the C behavior, we have to additionally list every single file in files to ensure that it's copied. So we have two lists of additional files in two different places.

I agree that this is a redundancy as well. Would you please add it to the list above?

I don't quite understand the points under "Should cmake files use relative paths?". I think yes they should! But I don't understand how this relates to copying. Maybe someone can shed some light?

I think this refers to the fact that cmake-include files are referenced with absolute paths in the generated CMakeLists.txt in the Cpp target.

I also don't understand the Cons of "How should we deal with target properties in imported files?". As far as I see, merging the cmake-includes of imported files would also work if the cmake files are resolved directly in the source directory. I don't understand why this would require copying.

Again, this argument I think is relying on absolute paths.

I think another important point to mention in this discussion is the one made here. If we rely on lfc to build federates on host machines, then we don't need to worry about the structure of the src-gen directory at all, since all we need to ship is the src directory.

I think I understand your argument a lot better now. However, I don't agree with this sentence: "all we need to ship is the src directory". Not always. Imagine a .lf file that imports other .lf files that are not in the same source directory. It might even be the case that the paths provided in the main .lf file for imports are absolute.

[cmnrd]

I think this refers to the fact that cmake-include files are referenced with absolute paths in the generated CMakeLists.txt in the Cpp target.

Ah, I see. I thought this is about paths in the source code, but it is about paths in the generated output. However, I don't think that absolute paths are a necessity here, since we can always convert absolute paths to relative paths using relativize(). We only need to define what the paths are relative to (I guess the project directory would be a good candidate).

However, I don't agree with this sentence: "all we need to ship is the src directory". Not always. Imagine a .lf file that imports other .lf files that are not in the same source directory. It might even be the case that the paths provided in the main .lf file for imports are absolute.

Right, it gets more complicated if multiple projects (multiple src directories) are involved. I don't think we should see this as a path problem though. To me, this is a packaging problem. Imports should always be relative to a package, and we shouldn't worry about where the package is located in the file system. This is really what a package manager should take care of.