Python bindings compilation for conda not finding boost/python/module.hpp

[Krande]

Hey,

when trying to compile the latest mgis using conda (more precisely using boa to build) I seem to consistently run into a "fatal error":

mgis-module.cxx:15:10: fatal error: boost/python/module.hpp: No such file or directory

I created a fork where I run a github actions comparing the same enabling flags using boa to compile versus compiling directly using cmake and make where this issue can be observed in the conda compilation, and NOT in the regular compilation: https://github.com/Krande/MFrontGenericInterfaceSupport/actions/runs/5876757460

When running with VERBOSE=1 I notice that the working regular compilation manages to keep the python include directory (in-between the "src/include" and the "prefix/include/python3.9").

• Working: link

  -isystem /home/runner/work/MFrontGenericInterfaceSupport/MFrontGenericInterfaceSupport/bindings/python/include 
  -isystem /home/runner/micromamba/envs/test-env/include 
  -isystem /home/runner/micromamba/envs/test-env/include/python3.9

• Not Working (conda): link

-isystem $SRC_DIR/bindings/python/include 
-isystem $PREFIX/include/python3.9

I've tried a lot of different things (different versions of python, boost, different python_dir flags etc.), but it seems I might have to make some changes to some of the CMakeLists.txt files. Any idea what this could be caused by and where I should start to look?

Let me know if you need any more information,

Best Regards Kristoffer

[thelfer]

Hi @Krande,

Thanks for your efforts !

Would you try the conda built by passing the following arguments to cmake: -DUSE_EXTERNAL_COMPILER_FLAGS=ON -Denable-portable-build=ON , although the latter is probably useless with USE_EXTERNAL_COMPILER_FLAGS ?

The short story is that we don't use CFLAGS and CXXFLAGS by default. Wheter this is a good thing is a matter of opinion. The -DUSE_EXTERNAL_COMPILER_FLAGS=ON changes this behavior.

Normally you shall also do this for TFEL.

Thomas

[Krande]

Hey @thelfer, and thank you for your responding so quickly!

Adding -DUSE_EXTERNAL_COMPILER_FLAGS=ON worked perfectly!

Feel free to close this issue

[thelfer]

@Krande Great ! Do you intend to propose an official conda package ?

[Krande]

@thelfer Further down the line, yes. Right now I am just going through all dependencies of code aster v15.8.0 and v16.4.2 and ensuring that I'm able to compile them using conda.

If you want, I can help set up mgis as a conda-forge package once I'm done with the code aster dependencies?

[thelfer]

@Krande That would be great ! If I may, that would be nice to do the same for TFEL as well ! Regards, Thomas

[Krande]

Sure, no problem!

Btw, I think TFEL (also known by mfront right?) is already distributed on conda-forge:

packaging repo: https://github.com/conda-forge/mfront-feedstock package: https://anaconda.org/conda-forge/mfront

I see mfront on conda-forge is only compiled for linux. I would like to add packages for windows also (I can make a PR to that package repository) if it possible to compile for windows

[thelfer]

Do you know whose the maintainer of this package ?

[thelfer]

I remember that I tried to make a conda package, but failed miserably :)

[Krande]

The maintainer of the conda-forge package of mfront is Luca Dall'Olio.

He has already managed to compile code aster v14.8 and is distributing it on conda-forge. I hope to contribute on the newer versions with code aster as a python module :) (a task which I've found is not easy, but doable )

Btw: With the newer conda tools such as mamba and boa iterating on building conda packages is much much faster. So it makes for a much better development experience :)

[thelfer]

@Krande Thanks for the information.