Make an install/setup script

[petr-tik]

Given the final distribution will be a python package, we should decide on a setup/install script for installations on localhosts. After that, I will make the corresponding Dockerfile and make docker resemble a local install as much as possible.

Ideally, the program should run in the same way locally and in container with dependencies under the same path and tests harness available locally and in docker.

Starting with dependencies: Catch, cereal and variant externals are header-file dependencies referenced at specific commits and we can git clone repo && cd repo && git checkout && cp include/ /usr/local/include/repo_name

clang_cpp_code_model can be installed into /usr/local/bin/ Need an install script for that too.

An uninstall option for ffig will go through and rm -rf all deps from specified locations.

If you agree to do that as part of setup/locally, we can reuse the same install script in the Dockerfile. After that, we can remove the externals/ dir, which will make your project even easier to install and allow docker to cache intermediary images.

What else is the build process missing?

[ajbennieston]

It would be good to provide a way to install to locations other than /usr/local.

If this is to be a Python module it should follow best practice for Python module setup/install; whatever that is these days. I had intended to look at this tonight.

[petr-tik]

That was just a suggestion to give a concrete example. Options where to install is a good idea for the future, I would agree on a default location, so we can get a working prototype asap.

What are good defaults?

[ajbennieston]

I think my point was there are no good defaults. /usr (and /usr/local) are off limits in many systems. At the very least, any install script should be provided with something like a --prefix= (configure style) or similar.

I think the best approach would be to follow the latest recommendations for a Python package. This would ensure that we are compatible with people installing into a virtual env, etc.

[jbcoe]

This is blocked by issue #52

Once we have FFIG.py and some template files, all we need to install for a user is FFIG.py and the template files. There are dependencies on other Python modules, but that's it.

The user will need to install libclang (it's a dependency of clang.py, which we depend on) and let FFIG know where to find it. Flexibility is king here.

I don't think that FFIG should be building shared libraries for now, just producing source files from headers and templates. That will keep the user requirements simple.

To use the generated files the user may or may not need extra libs, CMake etc. Let's defer handling those for now.

[petr-tik]

Ok, then I can take care of docker installation problems descrubed in #56, by putting the specific header files into /usr/local/include during the early stage of container build.

[jbcoe]

I'll try and make a start on this today.

[jbcoe]

This issue is still important and would get FFIG into PIP if we could close it.