binary extension package must be separated from the pure python one.

[stefanoborini]

The build system currently is out of best practices. The reason is that the setup.py delegates to a install_foam_interface.sh that does compilation and installation of an unrelated package, including installing on the user's home directory.

To accommodate edm packaging this has to change.

1. extension module and libraries must be in a separate repo and package, and packaged as a separate egg.
2. simphony-openfoam becomes a purely python entity, with the binary extension as a dependency

Without this change, porting to EDM is pretty much impossible.

[dpinte]

@stefanoborini if you move the python install[1] call out of the sh script, you should be able to common.local_repo_to_edm_egg(".", name=xxx, version=xxx, build=xxx) on the openfoam-interface/internal-interface/wrapper directory and get an egg out of it.

[1] https://github.com/simphony/simphony-openfoam/blob/master/install_foam_interface.sh#L37

[stefanoborini]

@dpinte Not really, the setup.py install actually creates the extension. Also, I work under the assumption that one repo = one egg. I would have to generate two eggs here.

[stefanoborini]

Additionally, all those commands end up installing the .so files under my home directory. They should really be part of the resulting egg, but then openfoam needs to find them.

[dpinte]

@stefanoborini

• the .so files can be added in the egg using the endist.dat. If you get them copied to usr/lib in the egg they will be copied at the right place when the egg will be installed.
• I am not sure how hard it will be to improve buildcommons to support directory based builds. My feeling is that it will be much easier than trying to split this repository in two separate ones. Looking at https://github.com/simphony/buildrecipes-common/blob/master/common.py#L72, it would probably even work from scratch. You could put a packaginfo in the wrapper directory and building the egg should work.
• who decides to put the files in your home directory? Is it wmake? or is it something else? Getting rid of that or copying the files after they are build should not be too hard to do, no?

[stefanoborini]

@dpinte

1. yes, that is possible. Just not very elegant.
2. there's a "version 2" of that module here https://github.com/simphony/buildrecipes-common/blob/master/buildcommons/__init__.py#L84 that builds from a local repo.
3. I think it's wmake, but I would have to investigate further. In any case, I expect it will need some combing for the rpath.

That said, putting everything inside one egg feels like a hack. They are two separate modules. They are installed as separate modules, and they just live in the same repo. It would eventually make a bit more sense that at least the python extension is part of the current main setup.py, not of the other setup.py.

[dpinte]

@stefanoborini I am not suggesting to put everything into the same egg. I think we need to keep two eggs separated. Having to rebuild the openfoam extension when you make changes to the pure python code, would not make sense.

For the rpath, let's see what happens when packaged. I suspect it will work as expected.

[dpinte]

@stefanoborini now that #101 is merged, do we need to keep this open?

[stefanoborini]

@dpinte I still think it's kind of wrong to have that setup. #101 is a workaround.