Open stefanoborini opened 7 years ago
@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
@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.
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.
@stefanoborini
usr/lib
in the egg they will be copied at the right place when the egg will be installed.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.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?@dpinte
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.
@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.
@stefanoborini now that #101 is merged, do we need to keep this open?
@dpinte I still think it's kind of wrong to have that setup. #101 is a workaround.
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.
Without this change, porting to EDM is pretty much impossible.