Commit graph

3 commits

Author SHA1 Message Date
Olivier Goffart
0553ab8b1a Use env::var_os instead of env::var
For the unliekly case in which the git repository is checked out in a directory
that cannot be represented with unicode
2020-06-05 13:45:37 +02:00
Simon Hausmann
33cfe03dc9 Rework the C++ facing build system, part 1
The objective is to automatically create a propery cmake module, with a
FindSixtyFPSConfig.cmake, corresponding targets .cmake files, etc. This
should encapsulate the build profile (debug vs. release) and also allow
making the choice of shared vs. static transparent.

Unfortunately it does not seem to be possible to easily combine different
crates into one cdylib crate that can re-export symbols from the
statically linked rust crates (cbindgen generated, as well as manual
extern "C").

That means for the dynamic case (not cared for right now), we're going
to need to create either one cdylib per crate that has public symbols or
manually re-export the symbols.

For the static case, linking just against the "last crate" in the chain
(the gl renderer backend) is sufficient to pull in all needed symbols.

In addition for the static case we need to specify the linkage of some
external libraries. This can be extracted manually via

    cargo rustc -p gl -- --print=native-static-libs

for example. For now that's in the changed CMakeLists.txt, but the plan
going forward is to automate this extraction in an xtask, to paste that
into the cmake target.

Finally, both linkage scenarios require access to the headers. This is
for now solved by generating them simply in an include sub-directory of
the build folder ($root/target/${profile}/include).
2020-06-04 15:29:19 +02:00
Simon Hausmann
83eb00b080 Run the C++ generated component through the GL backend
... which in turn forward to the corelib, but with the GL renderer attached.
2020-05-11 15:05:33 +02:00