SymbiFlow / conda-packages

Conda build recipes for the toolchains needed by LiteX / MiSoC firmware
https://github.com/mithro/HDMI2USB-litex-firmware
Apache License 2.0
2 stars 10 forks source link

Attempt to fix Surelog build: we need python development files. #111

Closed hzeller closed 4 years ago

hzeller commented 4 years ago

Fixes #105

Signed-off-by: Henner Zeller h.zeller@acm.org

hzeller commented 4 years ago

Let's see if this works.

hzeller commented 4 years ago

(not merge yet, work in progress)

hzeller commented 4 years ago

So, python-dev is not the right package: https://travis-ci.com/github/SymbiFlow/conda-packages/jobs/352794276#L1297

How do I get Python development files (Python.h and shared lib)?

Adding @mithro as he most likely knows all things Python related.

Travis CI - Test and Deploy with Confidence
Travis CI enables your team to test and ship your apps with confidence. Easily sync your projects with Travis CI and you'll be testing your code in minutes.
hzeller commented 4 years ago

Anyone of you knows what the right conda package is to get Python development files ? Searching on Anaconda did not enlighten me much ...

mithro commented 4 years ago

@hzeller They are in the "python" package -- the issue is cmake not finding them properly.

hzeller commented 4 years ago

Cmake finds the Interpreter, but not the Development files.

I have seen something like that on some workstation where the python interpreter it finds is a different version than development files that might be on the system (available was 3.7 with interpreter and development, and 3.8 with only interpreter); unfortunately the cmake rule does not do an exhaustive search of versions where it has one and the other. On a workstation, I can fix that by uninstalling a stray version of Python (in that case above, if 3.8 is removed, it found Interpreter+Development).

I suspect something like this is going on in this conda-build, so that possibly the python install provides a new version of the interpreter, but not the new version of development files. Or maybe it provides both, but cmake finds the 'other' version of Python on the build machine.

PiotrZierhoffer commented 4 years ago

@hzeller In prjtrellis package we have the following (https://github.com/litex-hub/litex-conda-eda/blob/master/bit/prjtrellis/build.sh#L23)

    -DPYTHON_EXECUTABLE=$(which python) \
    -DPYTHON_INCLUDE_DIR=$(python -c "from distutils.sysconfig import get_python_inc; print(get_python_inc())")  \
    -DPYTHON_LIBRARY=$(python -c "import distutils.sysconfig as sysconfig; print(sysconfig.get_config_var('LIBDIR'))") \

If you can run the interpreter before running cmake, maybe this is the easiest way to approach it?

GitHub
litex-hub/litex-conda-eda
Conda recipes for FPGA EDA tools for simulation, synthesis, place and route and bitstream generation. - litex-hub/litex-conda-eda
PiotrZierhoffer commented 4 years ago

Using these variables is also mentioned here: https://cmake.org/cmake/help/v3.0/module/FindPythonLibs.html

FindPythonLibs — CMake 3.0.2 Documentation
PiotrZierhoffer commented 4 years ago

Agreed. I thought this problem is there despite having python in the build section.

tgorochowik commented 4 years ago

@hzeller I reopened #107 in which besides moving the python requirement I modified the build instructions to mimic what we do for the uhdm-integration packages (for which the surelog build works).

hzeller commented 4 years ago

Closing. #107 is the right one.