Distribute scripts no longer work

[edwardalee]

When generated a federated program, a distribute.sh script is generate to distribute and compile the generated code on remote servers. This no longer works, presumably as a consequence of the reorganization of project structure. Is there any way to add tests for this?

[lhstrh]

We can add a step to the test framework that executes the generated distribute script (if one exists).

[Soroosh129]

With the merging of #449, distribute scripts should be functional, but only on Linux machines. This is because (if CMake is disabled) lfc is responsible for detecting the platform and adding the support files, and lfc can only detect the local machine, not remote federate machines.

Enabling our CMake build system for remote machines fixes this issue because the generated CMakeLists.txt can detect the appropriate platform and add the appropriate support files on the remote machines automatically, without involving lfc. However, our current CMake build system cannot currently be used for remote federates because it uses absolute paths in many places.

[cmnrd]

Why do we invoke the target compiler (or build tool) directly on the host machines? This always means that we need to have global knowledge about all our hosts (or make assumptions). In consequence, we need either a homogenous set of machines, or we have a very complex launcher script that allows for heterogeneity. Both are not ideal in my opinion. I think lfc is already great at compiling LF programs locally without making too many assumptions on the system. So why not run lfc on each host and let it compile a specific federate (we could easily introduce CLI flags that allow to specify a federate)? Since lfc is a jar, we can copy it to remote machines and run it on any machine with a JRE.

[Soroosh129]

I'm not sure if there is an advantage in invoking lfc rather than GCC or CMake. I think most, if not all, aspects of the generated code that are platform-dependent are already, or can be made to be, resolved at compile time. Invoking lfc on remote machines will duplicate the code generation process, which doesn't really change from platform to platform. We can make lfc smarter to only partially generate code for each federate and somewhat avoid this problem, but we are adding Java as a requirement for the remote machines, and we might not gain any more control than what CMake already gives us.

[cmnrd]

I think the key advantage of using lfc is that it allows us to have a very simple target independent (and to some degree platform independent) launcher script. Without implementing complex logic, such a script based on lfc could even support federations that mix multiple target languages, and/or where you want to use different compilation mechanisms on different hosts. It would be the responsibility of each lfc run to compile the federate's code in the correct way, and we would not need to replicate that logic in a script.

Another advantage would be that we don't need to generate code in a platform independent way. We can always generate code for the specific platform in use. This also reduces complexity in the generated code as well as in the code generators. Take for instance the path problem you mention: dealing with absolute paths is much simpler than worrying about relative paths and how to resolve them (that's why we use them, at least in the C++ target). I personally would rather run lfc on the host than trying to generalize the generated code and launcher script.

As long as we only run C federations, this probably doesn't matter much. But if we add more targets and features, the launcher script is likely to become too complex.

[lhstrh]

I think @cmnrd makes a good point. I expect that an lfc-based approach would mesh well with technologies like Docker or Kubernetes, which would allow us to create a much less ad-hoc build and deployment mechanism than the shell scripts we've been using.

[lhstrh]

We could either make a selection of federates to generate code for based on instance names or by selecting a particular host. As a default, we could generate code only for federates mapped to localhost. @Soroosh129, @edwardalee: what do you think about this?

[Soroosh129]

I don't see what lfc can offer if we make the generated source code portable enough. It would be an added dependency that will require Java to be present on the remote machines. Our launch and distribute scripts are really quality of life features. Any orchestration mechanism should in theory be feasible with a portable generated source code in my opinion.

[edwardalee]

I suspect a docker image that can run lfc will be much larger than a docker image that only needs to run gcc, but I'm not sure. The current mechanism for docker images, as I recall, removes all the compiler dependencies after the compile completes. I suppose it might be possible to do that with lfc as well.

I have to say, however, that this is not a priority for me. If someone else wants to fully explore this, have at it...

[lhstrh]

But in this comment you point out things only work based on the assumption that remote hosts run on Linux, the reason being that its not knowable during code generation what platform remote hosts use. @cmnrd's point was that we don't need to know if, instead of having a script that executes target build commands, we have a script that invokes lfc. This simplifies matters. The only difference is that instead of requiring a Linux platform (with appropriate compiler tools installed), we don't require a specific platform but rely on the JVM. Arguably, that is a leaner requirement, not a stricter one. Of course, we can also just sort out the path issues with cmake and rely on that.

[Soroosh129]

But in this comment you point out things only work based on the assumption that remote hosts run on Linux, the reason being that its not knowable during code generation what platform remote hosts use.

In our distribute scripts. An easy fix is to put all platform files on remote machines and let CMake figure out the exact dependencies needed. That is my current plan anyway.