JITlib doesn't clean up

[mzarrawork]

How we use trick here at KSC SLS: We put various trick simulations onto our linux box, and some are newer versions of the trick simulation. Then we run our simulation. We can go back and forth with the older or newer version.

The issue occurs when we switch because certain objects don't exist between the two simulations and the makefiles don't regenerate the .so, .o, and .d.

There is also a bug in the jitlib input file that ruins the clean up of the .d file (double output then you append the dependency file name). So that needs to be fixed regardless.

We essentially want trick to clean up the jitlib folder or recompile properly. I can see a use case where someone would want to not have to wait for a recompile via JIT per shutdown and starting back up of a simulation, so cleaning the jitlib folder out might not be a good idea during shutdowns. So basically, there has to be a way for trick to either "understand" that this is a newer version of the simulation and clean up jitlib folder and recompile or just be able to recompile. Or maybe a flag we set when executing S_main or an environment variable to force trick to do a clean before trick does a make in JIT.

[hchen99]

Thanks for reporting. We'll be looking into this.

[hchen99]

@mzarrawork The path for the .d file is fixed for clean target in the Makefile.input in the branch for this issue. Feel free to give it a try to see if it is what you're expecting

In terms of "The issue occurs when we switch because certain objects don't exist between the two simulations and the makefiles don't regenerate the .so, .o, and .d.":

• If any associated header files (based on S_source.hh) are changed when switching back and forth from one sim to another, .so, .o, and .d were regenerated as I tested.
• For testing purpose, also, tested that those files are regenerated if rebuilding the sim after it's cleaned.
• Of course you could also make -f RUN_xxx/jitlib/Makefile.input clean to manually clean those files before you run your sim as you know.
• We could add a flag for S_main_ to force those files to be regenerated. Wanted to make sure if I understood the issue correctly and the necessity to add the flag.