The time required grows with the number of included header files and can represent a significant portion of the build process. During subsequent builds, only headers files that have changed are reprocessed. However, `make clean` removes all of the generated files, so the next build will have to run the entire process again.
For external libraries, which do not change from build to build, this is unnecessary and wasteful. In this case, we would like to compile the `io_*.cpp` and `*_py.cpp` files once and simply link against them during simulation build. As of version 17.1, Trick supports "Trickifying" a set of headers via the `trickify.mk` makefile.
Support of Trickification is the project owner's responsibility. While it is possible for anyone to Trickify any set of headers, you really want the project to maintain the files we're going to talk about. This will ensure that's it done correctly, in one place, and stays synchronized with the project.
# Trickifying Your Project
Trickifying your project requires a list of headers and the paths at which they can be found. This list should include the headers for which you want data recording, checkpointing, and Python access, which probably means most or even all of them. Specify the list by creating a file named `S_source.hh` that includes the headers you want processed and nothing else. This is not the same `S_source.hh` generated by Trick during the simulation build process, but Trick's tools expect that name, so you have to use it for now. Specify the header paths via the `TRICKIFY_CXX_FLAGS` variable, which you can set when you call `make` or export from your own makefile. I don't recommend setting it in your shell via `export` or `setenv`. All of Trick's environment variables can be specified at compile time, exposed at run time, and limited to the duration of the executable. There's no reason to permanently pollute your environment from your `.cshrc`, `.bashrc`, etc.
For example, say we have a tiny project that looks like this:
<pre><b>${HOME}/myproject/
include/
Foo.hh
Bar.hh
Baz.hh</b></pre>
To Trickify this project, we'll make a file called `S_source.hh` which includes all three headers:
```c++
#include "Foo.hh"
#include "Bar.hh"
#include "Baz.hh"
```
I recommend putting your `S_source.hh` in its own directory since Trick is going to generate a bunch of files, for some of which you can't yet specify the output directory. Let's call it `trickified`:
<pre>${HOME}/myproject/
include/
Foo.hh
Bar.hh
Baz.hh
<b>trickified/
S_source.hh</b></pre>
In the `trickified` directory, run:
```bash
make -f ${TRICK_HOME}/share/trick/makefiles/trickify.mk TRICKIFY_CXX_FLAGS=-I${HOME}/myproject/include
`trickified.o` contains all of the compiled `io_*.cpp` and `*_py.cpp` code. The name is configurable via the `TRICKIFY_OBJECT_NAME` variable, which can include directories, which will automatically be created if necessary. `build` contains a lot of ICG and SWIG artifacts. You can't change its name or location at this time, but it's useful to keep around as it will allow you to rebuild only the parts of the project that change in the future, and sims that build against your project will need the `*_py.i` files within. `.trick` includes a bunch of crazily-named Python modules which serve as the input file interface to the content of the header files. Those modules are compiled and zipped into `python`. The zip file name is configurable via the `TRICKIFY_PYTHON_DIR` variable, which can include directories, which will automatically be created if necessary.
Your Trickified library can be produced in three different formats based on the value of `TRICKIFY_BUILD_TYPE`:
1.`STATIC` (.a)
Create a static library. This will require the use of `--whole-archive` (on Linux) or `-all_load`/`-force_load` (on Mac) when linking the sim executable. Trick uses `dlsym` to dynamically load symbols at run time, but the linker, by default, will not include symbols from static libraries that are not known to be needed at compile time.
2.`SHARED` (.so)
Create a shared object (dynamically linked library). This may require the use of `-rpath` to ensure the linker can find the shared object at runtime unless you explicitly link against it (as opposed to using `-L` and `-l`) during compilation.
3.`PLO` (.o)
Create a partially-linked object (see the `--relocatable` option of `ld`). No special linker options are required. This is the default build type.
Note that Trick does not automatically append file extensions and will use the value of `TRICKIFY_OBJECT_NAME` regardless of the value of `TRICKIFY_BUILD_TYPE`.
## Simplify with a Makefile
Let's be honest. You're not going to remember that command line. And who wants to type all that stuff every time? Let's do it once in our own makefile and just call `make` on that. It seems sensible to put this in the `trickified` directory right next to `S_source.hh`.
Now just type `make` in `trickified` and everything is taken care of. I even added a check to make sure you're using a recent enough version of Trick. I've silenced a lot of make's output because I prefer to see echoed commands only when debugging, but you're welcome to get rid of the `@` and `-s` if you enjoy such verbosity. Note that I've used `TRICKIFY_OBJECT_NAME` to rename the default `trickified.o` to something a little less generic. If you're following along, you can remove the `trickified.o` we built earlier.
## Don't Version Control Build Artifacts!
The only Trickification-related files you want under version control are `S_source.hh` and `Makefile`. You should ignore all of the generated files. For instance, the appropriate `.gitignore` for the `trickified` directory when using default values for the Trickification variables is:
The generated Python modules can be particularly problematic if they are accidentally version controlled. The names are created by hashing the full file path, both during Trickification and again when the sim is built. If the paths change between Trickification and sim compilation, the names won't match, and you'll get confusing linker errors.
# Using a Trickified Project
Using a project that's been Trickified is a lot like using an external library, but there are a couple of extra things to take care of. Continuing with the example above, we would need to add the following to our sim's `S_overrides.mk`:
This line links in the Trickified object. Note that you may need additional flags if you used `TRICKIFY_BUILD_TYPE` to build a static library or shared object.
This line tells Trick to expect `io_*` and `*_py` code for the headers in the specified directory (and all directories below it), but not to generate it itself. This is different than `TRICK_ICG_EXCLUDE` and `TRICK_EXCLUDE`, which cause ICG to ignore the headers entirely. It also tells Trick not to compile any source files in the specified directory (and all directories below it) that may be referenced as `LIBRARY_DEPENDENCIES` in user files. Note that it is a colon-delimited list of paths.
You'll need to be more selective if the sim itself or additional non-Trickified headers or source are under the same directory as Trickified headers or source. You may have to resort to individually specifying the full path to every file to be excluded, perhaps using some fancy `find` options to automatically generate the list.
This line tells Trick where to find the zipped Python modules generated by SWIG so that you can access the Trickified project from the input file. It is also a colon-delimited list of paths.
This line tells Trick where to find the `*_py.i` files generated by ICG and should point to the directory containing `build`. These are necessary if any of your headers include headers from the Trickified project, which is likely, since you otherwise wouldn't be using it. It is a space-delimited list of options. Don't forget to prepend the path with `-I`.
While the above is sufficient to use a Trickified project, it's awfully inconvenient to have to add all that stuff to every sim's `S_overrides.mk`. Plus, there are probably more things that need to be added, like header paths and linker flags for any additional libraries on which the project depends. Your users will love your project even more if you provide them with a makefile they can simply include from their `S_overrides.mk`. And it's not just the users that benefit! You'll have to answer far fewer questions about why they can't get your project compiled into their sim if, when your project inevitably changes, all they have to do is pull down the new makefile instead of changing all of their `S_overrides.mk`. Everybody wins! Turning once again to our example, let's call the makefile `myproject.mk` and put it in the `trickified` directory. You may have a name or location that makes more sense for your project. Maybe you already have a `makefiles` directory, or maybe your project supports a number of third party tools and you have a directory for Trick support. But let's keep the example simple:
# Append a prerequisite to the $(SWIG_SRC) target. This will build the
# Trickified library along with the sim if it does not already exist. Using
# $(SWIG_SRC) ensures that all Trickified .i files are created before SWIG is
# run on any simulation .i files, which may %import them. Note that this does
# NOT cause the Trickified library to be rebuilt if it already exists, even if
# the Trickified source code has changed.
$(SWIG_SRC): $(MYPROJECT_TRICK)
endif
$(MYPROJECT_TRICK):
@$(MAKE) -s -C $(MYPROJECT_HOME)/trickified
```
Now to use your project, all the user has to do is add one line to his `S_overrides.mk`:
```make
include <myproject>/trickified/myproject.mk
```
They'll have to replace `<myproject>` with the location to which they installed your project, of course. They might choose to hardcode the path or use a variable, but that's up to them.
Trickification is great and all, but it only builds the `io_*` and `*_py` code into an object. And because your project's headers and source are now under `TRICK_EXT_LIB_DIRS`, Trick won't be determining dependencies or compiling source code. Trickification thus necessitates that you build all of your source code into a library. There are plenty of internet tutorials available on that topic, so I won't be suggesting anything here. But once you've got that taken care of, you should incorporate it into your user-facing makefile by adding it to `TRICK_LDFLAGS`. You can also create a rule to call its build system and add the library as a prerequisite to `$(S_MAIN)` to have it built along with the sim if necessary.
Here's a real project we used as the guinea pig for Trickification. It provides a makefile that a user can include from his `S_overrides.mk` that causes both a core library and Trickified object to be built if they don't already exist whenever the sim is compiled. The makefile is located at `3rdParty/trick/makefiles/trickified.mk`. The Trickified stuff is at `3rdParty/trick/lib`.
https://github.com/nasa/IDF
[Continue to Running A Simulation](../running_a_simulation/Running-a-Simulation)
