An idea to solve both the toolkit overwriting and file location problem
The Java toolkit creates C++ files in the application directory ("output Directory"). This creates (amongst others) two problems:
- In large applications, users cannot freely structure their code in subdirectories
- Users cannot understand which files are overwritten and which not
To address problem (1), I recently introduced an heuristic approach, FileSearch.java. This allows to put a file with a similar name in any subdirectory in the output directory. Thus, for instance, we can have an application to be structured in folders like
SRMHD ├── C2P-MHD.f90 ├── C2P-MHD.h ├── C2PRoutines.f90 -> ../SRHD/C2PRoutines.f90 ├── ExaHyPE-MHDSolver-p2 ├── extended.log ├── InitialDataAdapter.cpp ├── InitialDataAdapter.h ├── InitialData.f90 ├── KernelCalls.cpp ├── Makefile ├── make-p2.log ├── MHDSolver.cpp ├── MHDSolver_generated.cpp ├── MHDSolver.h ├── Parameters.f90 ├── parameters.mod ├── PDE.f90 ├── PDE.h ├── run_withEnv.sh └── Writers ├── ConservedWriter.cpp ├── ConservedWriter.h ├── ErrorWriter.cpp ├── ErrorWriter.h ├── ExactPrimitivesWriter.cpp ├── ExactPrimitivesWriter.h ├── IntegralsWriter.cpp ├── IntegralsWriter.h ├── PrimitivesWriter.cpp ├── PrimitivesWriter.h ├── RelativeErrorWriter.cpp ├── RelativeErrorWriter.h └── TimeSeriesReductions.h -> ../../EulerFlow/TimeSeriesReductions.h
ie. note the
Actually, this ticket shall propose an idea which solves the problems (1) and (2) altogether.
Defining a header
My idea proposes to define a magic line at any place (ie. header or footer) of the generated
.cpp files, containing something like:
/** ExaHyPE.jar: autogenerated at Fr 3. Feb 19:08:51 CET 2017 **/ /** ExaHyPE.jar: File identifier: Plotter[i].HeaderCode **/ <- this is the identifier line /** ExaHyPE.jar: Rebuild options: [x] Rebuild on every toolkit call [ ] Manually disable rebuild [ ] Rebuild on structural change **/ <- This can be changed by user
The identifier line solves the problem to find an appropriate file. It allows users to rename them as he wants. The toolkit has to inspect all possible files with a
grep like search, but this is not too bad. We don't really expect too big applications...
The options line allows the user both to understand the default setting and to enforce his own rules. This is very helpful when working at ExaHyPE internals and to stop this long lasting conflict with the toolkit overwriting stuff. It also allows users to request an overwrite of a file. The specific syntax is open to discussion, ie. one could also choose something better machine readable here.