Build problems in Cpp target

[edwardalee]

When building a Cpp target application test/Cpp/Composition.lf in Eclipse, the console reports:

Compiled binary is in /Users/eal/git/lingua-franca/test/Cpp/bin/Composition

But that file is an old file created by a prior run of run-lf-tests.

Using Apple’s Spotlight and checking dates, I found an executable file called Composition that has the right date and time here:

/Users/eal/git/lingua-franca/test/Cpp/src-gen/bin/Composition

This one actually runs, unlike another executable file with the same name and date found here:

/Users/eal/git/lingua-franca/test/Cpp/src-gen/build/Composition/Composition

So the first problem is that Eclipse is putting files in the wrong place (or at least reporting the wrong place).

The second problem is that the IDE is pretty unusable with the Cpp target because it constantly rebuilds everything and the build is quite slow… Perhaps the reason it is rebuilding everything all the time is that that it is checking the dates of files in the wrong directory, then rebuilding and putting the results into another directory? This will lead to the build system always concluding that the build files are out of date.

The rebuild takes much longer than a clean rebuild of all the tests in the C target. So I really don’t think we want to emulate this build system in the C target until we figure out why it takes so long.

Here are the stats:

A clean build in Eclipse of the tests/Cpp project, which has 71 tests, takes 14 minutes. A clean build in Eclipse of the tests/C project, which has 116 tests, takes under 3 minutes.

Running the regression tests is equally bad:

EALMAC:Cpp eal$ time run-lf-tests Cpp >& test.txt; bbedit test.txt

real    15m38.963s
user    20m52.353s
sys 1m13.667s

71/71 tests passed.

Compare with the C target:

EALMAC:Cpp eal$ time run-lf-tests C >& test.txt; bbedit test.txt

real    4m30.576s
user    10m42.487s
sys 0m48.220s

116/116 tests passed.

(I presume that the reason that the user time exceeds the real time is that it is using more than one core).

[cmnrd]

I think there are two separate issues here. There is the issue of placing files in the wrong place and the issue of compilation time.

The issue of Ecplise placing the generated binary in src-gen/bin is strange and not the expected behavior. It would be possible that this is an unexpected side effect of the import system changes or some other change. I will look into this.

I cannot really say anything about the cyclic compilation in Ecplise. I know that you reported this several times now, but I was never able to reproduce this issue. I also don't know the inner workings of Eclipse, so I cannot really comment on possible causes.

The compilation time for C++ is indeed much larger than the one for C. This has multiple reasons:

1. C++ uses a two stage build process where cmake produces make files and then make runs the actual compilation. That takes some time.
2. We generate multiple source files in C++ that all need to be compiled. Although these compilations can be run in parallel, it still takes longer than compiling the single C source file. In addition, we also need to compile reactor-cpp (This happens only once for all the tests though).
3. Since the C++ code is split in multiple files and we depend on an external library, we need to run the linker to produce a binary
4. On default, cmake calls the compiler with various optimization options (including link time optimization) enabled. I am not sure how this compares to the C build process.

It is a petty that this renders Eclipse useless for C++. I think we should really change the default behavior of our IDE. While it is fine that Eclipse insists in generating source code, I think we should refrain from automatically triggering the compiler on this generated code. Instead, we could introduce a compile button that triggers the target compiler when the user sees fit.

[cmnrd]

I pushed a fix that places the binaries in bin/ and not in src-gen/bin when compiling from Eclipse and from the command line.

Could you check if this influences your issue with cyclic builds in Eclipse?

I usually don't compile from Eclipse because it insists in compiling everything which takes way too long. I would be happy if we can resolve this somehow. What I currently do, is to remove the tick under Project>Build Automatically. This, at least, makes the IDE usable. It is also possible to trigger build for individual projects manually. However, usually I just use lfc.

[lhstrh]

One obvious optimization seems to build reactor-ts once and link it as a library rather than keep rebuilding it for every program.

[cmnrd]

I am confused by your comment. Are you actually talking about TS or did you mean reactor-cpp? The reactor-cpp is currently only build once per project/directory. This generally works but comes but also makes the build process as bit fragile as different reactor programs can specify different build settings that would also apply to the library. This can potentially create inconsistent builds. I hope to make this more robust when we have something like a package or project configuration.

Once we have this wider configuration per package or project, we can also do another optimization. Generate all C++ code and cmake files for the entire package, run cmake once, and then build all the binaries in one go (effectively exploiting parallel hardware as we can link multiple binaries at once and linking is the most time consuming part of the build process.

[cmnrd]

Closing this. The path problem is resolved and regarding compilation time we have #355