Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hints to build with Win10 / VS2019 / Python 3.7 #28

Open
incensesmoke opened this issue Nov 27, 2019 · 27 comments
Open

Hints to build with Win10 / VS2019 / Python 3.7 #28

incensesmoke opened this issue Nov 27, 2019 · 27 comments

Comments

@incensesmoke
Copy link

incensesmoke commented Nov 27, 2019

For a Win10/VS2019 build with a Python3.7 wrapper and SWIG4.0.1 I had to make the following changes in the current master BTK-core:

Perhaps this can save somebody else some trouble. As a n00b this took me a long time to figure out ;) Now it passes all tests and I'm happy!

Edit: spelling

@jimmyDunne
Copy link

May want to try https://github.com/pyomeca/ezc3d

@incensesmoke
Copy link
Author

Thanks for the link! I'll look into it

@melund
Copy link

melund commented Dec 2, 2019

@incensesmoke Could you push the changes you did to your fork of BTK?

I would really love to get conda-forge to build conda packages of BTK for Python 3.

melund added a commit to melund/BTKCore that referenced this issue Dec 3, 2019
melund pushed a commit to melund/BTKCore that referenced this issue Dec 10, 2019
Enable Python 3 build

Moved the *.tpp includes from the .h to the .cpp.

Fix the problem with using BTK in other libraries (like OpenSim) on Windows.

Problem -- Including the BTK headers causes an error on Windows with VS2015.
           " .... cstdint: 'uint8_t' is not a member of global namespace .... ".
           The error appears to be in the standard library but is actually
           caused by the fact that Utilities/stdint.h is included for MSVC
           builds and the directory Utilities is in the include path for the
           compiler. When trying to search for a header named stdint.h, the
           compiler keeps running into Utilities/stdint.h even when the
           original intention was to find the header in the system standard
           path.
Solution -- Rename the file Utilities/stdint.h to something else that does not
            conflict with standard library header of the same name therefore
            avoiding compiler choosing this header when standard library header
            is meant to be found.

Fix RPATH for OSX.

Fix from Biomechanical-ToolKit#28

Remove xrange
melund added a commit to melund/BTKCore that referenced this issue Dec 11, 2019
melund pushed a commit to melund/BTKCore that referenced this issue Dec 11, 2019
Enable Python 3 build

Moved the *.tpp includes from the .h to the .cpp.

Fix the problem with using BTK in other libraries (like OpenSim) on Windows.

Problem -- Including the BTK headers causes an error on Windows with VS2015.
           " .... cstdint: 'uint8_t' is not a member of global namespace .... ".
           The error appears to be in the standard library but is actually
           caused by the fact that Utilities/stdint.h is included for MSVC
           builds and the directory Utilities is in the include path for the
           compiler. When trying to search for a header named stdint.h, the
           compiler keeps running into Utilities/stdint.h even when the
           original intention was to find the header in the system standard
           path.
Solution -- Rename the file Utilities/stdint.h to something else that does not
            conflict with standard library header of the same name therefore
            avoiding compiler choosing this header when standard library header
            is meant to be found.

Fix RPATH for OSX.

Fix from Biomechanical-ToolKit#28

Remove xrange

Avoid tr1 with VS2017

Biomechanical-ToolKit#28
@melund
Copy link

melund commented Jan 9, 2020

I have created a conda package for BTK which supports Python 3. It can be installed with:

conda install -c conda-forge btk

It currently has support for Windows. If anyone would help getting Linux/mac working that would great. I don't think it will be hard, I just haven't had the opportunity to try other compilers.

The build recipe is here:
https://github.com/conda-forge/btk-feedstock

I hope this will serve for anyone who needs BTK for older projects but can't use Python 2.7. I will not recommend it for new projects since BTK development has stopped.

Thanks a lot to:
@allardhoeve, @klshrinidhi, @chrisdembia, @aroy-hc
for all your fixes and commits which help get BTK Python 3 support.

also thanks to:
@incensesmoke, @CameronJGrant, @aaa34169, @jjnurminen, @demotu
Your posts and comments different places on Github helped me a lot to get the build working.

@aaa34169
Copy link

aaa34169 commented Jan 9, 2020 via email

@melund
Copy link

melund commented Jan 9, 2020

Good question and the answer is yes. The conda build recipe is setup to do that as part of the build. The build can only succeed if all the tests pass.

I had to adapt the test runner a little bit to handle the setup on the CI server used by conda forge. You can see it here:
https://github.com/conda-forge/btk-feedstock/blob/master/recipe/run_test.py

@aaa34169
Copy link

aaa34169 commented Jan 9, 2020 via email

@incensesmoke
Copy link
Author

Thanks @melund for doing the work I gave up on! Is it a lot of effort to also make a PyPi package? Perhaps to merge/augment @aaa34169's contribution there?

@melund
Copy link

melund commented Jan 9, 2020

Is it a lot of effort to also make a PyPi package?

I actually have no idea. I guess it is possible these days using wheels. But I think packages like this is exactly what conda is for. Distributing binaries with the python and real tracking of dependencies.

@jjnurminen
Copy link

@melund Thanks, this is great! Installs and works without a hitch on Win10 64-bit/Python 3.7.

@jjnurminen
Copy link

jjnurminen commented Jan 13, 2020

@melund Now that you established the build procedure, would it be possible to also build a 2.7 version of btk into conda-forge with small effort? I know this may sound silly, but I still need to maintain 2.7/3.7 versions of my package for some time. It would be great to be able to get the same btk conda-forge dependency regardless of whether Python 2.7 or 3.7 is used.

@melund
Copy link

melund commented Jan 13, 2020

I don't know if conda forge still supports building 2.7 packages.

You can try to make a PR to the recipe
https://github.com/conda-forge/btk-feedstock/blob/master/recipe/meta.yaml

where you change the 3.6 restriction. The CI system should then build a 2.7 version to check the PR. If 2.7 is supported that is :)

@jjnurminen
Copy link

@melund I tried, let's see what happens. Was not 100% sure about the syntax of the yaml file...

@melund
Copy link

melund commented Jan 13, 2020

It doesn't seem to do anything. I don't think conda forge builds for 2.7 any more.

@jjnurminen
Copy link

It doesn't seem to do anything. I don't think conda forge builds for 2.7 any more.

Ok, thanks. On quick googling, I couldn't find any mention of conda-forge dropping 2.7 though. Maybe I'll try again later.

@melund
Copy link

melund commented Jan 14, 2020

@jjnurminen Wait. I think the automatic CI generation removes the 2.7 build scripts when the recipe excludes python 2.7. I tried to re-render the recipe and now 2.7 is available:
conda-forge/btk-feedstock#3

We will see if also works. Maybe the Python 3 patch needs to be removed for 2.7

@jjnurminen
Copy link

Looks like the build failed, cannot find numpy?

melund pushed a commit to melund/BTKCore that referenced this issue Jan 22, 2020
Enable Python 3 build

Moved the *.tpp includes from the .h to the .cpp.

Fix the problem with using BTK in other libraries (like OpenSim) on Windows.

Problem -- Including the BTK headers causes an error on Windows with VS2015.
           " .... cstdint: 'uint8_t' is not a member of global namespace .... ".
           The error appears to be in the standard library but is actually
           caused by the fact that Utilities/stdint.h is included for MSVC
           builds and the directory Utilities is in the include path for the
           compiler. When trying to search for a header named stdint.h, the
           compiler keeps running into Utilities/stdint.h even when the
           original intention was to find the header in the system standard
           path.
Solution -- Rename the file Utilities/stdint.h to something else that does not
            conflict with standard library header of the same name therefore
            avoiding compiler choosing this header when standard library header
            is meant to be found.

Fix RPATH for OSX.

Fix from Biomechanical-ToolKit#28

Remove xrange

Avoid tr1 with VS2017

Biomechanical-ToolKit#28

Fix problem with test

Fixes a problem with unittest.assertAlmostEqual not working on numpy ndarrays.

Reporting that ndarray doesn't have a __round__ methods.

Fix test error
melund pushed a commit to melund/BTKCore that referenced this issue Jan 22, 2020
Enable Python 3 build

Moved the *.tpp includes from the .h to the .cpp.

Fix the problem with using BTK in other libraries (like OpenSim) on Windows.

Problem -- Including the BTK headers causes an error on Windows with VS2015.
           " .... cstdint: 'uint8_t' is not a member of global namespace .... ".
           The error appears to be in the standard library but is actually
           caused by the fact that Utilities/stdint.h is included for MSVC
           builds and the directory Utilities is in the include path for the
           compiler. When trying to search for a header named stdint.h, the
           compiler keeps running into Utilities/stdint.h even when the
           original intention was to find the header in the system standard
           path.
Solution -- Rename the file Utilities/stdint.h to something else that does not
            conflict with standard library header of the same name therefore
            avoiding compiler choosing this header when standard library header
            is meant to be found.

Fix RPATH for OSX.

Fix from Biomechanical-ToolKit#28

Remove xrange

Avoid tr1 with VS2017

Biomechanical-ToolKit#28

Fix problem with test

Fixes a problem with unittest.assertAlmostEqual not working on numpy ndarrays.

Reporting that ndarray doesn't have a __round__ methods.

Fix test error
@jjnurminen
Copy link

Hi @melund and others

I ran into an issue.

With Python 2.7, I used to convert strings to latin1, which btk ate happily:

c3dfile = 'some_file.c3d'
reader = btk.btkAcquisitionFileReader()
c3dfile = c3dfile.encode('latin-1')
reader.SetFilename(c3dfile)

With Python 3, the SWIG interface apparently eats Python 3 string type directly. So the above would simply read:

c3dfile = 'some_file.c3d'
reader = btk.btkAcquisitionFileReader()
reader.SetFilename(c3dfile)

Still good. However, using non-ASCII chars (which are rather common in Finnish):

c3dfile = 'söme_file.c3d'
reader = btk.btkAcquisitionFileReader()
reader.SetFilename(c3dfile)

 RuntimeError: File doesn't exist

even if the file actually exists. I tried encoding to UTF-8, but that results in

TypeError: in method 'btkAcquisitionFileReader_SetFilename', argument 2 of type 'std::string const &'

Any idea how we could get correct support for non-ASCII filenames? Maybe some compile-time flag for the SWIG interface?

@melund
Copy link

melund commented Feb 17, 2020

I don't think you need to do any encoding since Python 3 uses utf-8. This works out of the box for me:

image

@jjnurminen
Copy link

That's weird, I verified that I get a RuntimeError for any filename with non-ASCII characters. I suppose you're also on a Windows 10 machine?

@melund
Copy link

melund commented Feb 17, 2020

Does it help if you put # -*- coding: utf-8 -*-, as the first line of your Python files?

@jjnurminen
Copy link

@melund no, it doesn't seem to help. But strangely, the above code works just fine on another Windows 10 machine. So I suspect this particular Windows box has some special locale settings or whatever that screws things up. Anyway, thank you.

@aaa34169
Copy link

aaa34169 commented Aug 7, 2020

@melund

Hello, morten, i try to recompile your btk code ( branch tagged python3 ) . Unfortunaly i ran into an issue when the compiler try to wrap the code in python.

my configuration is :

  • windows 10
  • cmake 3.18.1
  • swig 4.0.2
    here is how i configure cmake :
    cmake-settings

at [98% ] Linking CXX shared module to ....\bin_btk.pyd
i have this errror message :
Error LNK2001 symbole externe non résolu "public: virtual short __cdecl btk::ByteOrderBinaryFileStream<class btk::VAXLittleEndianFormat>::ReadI16(void)" (?ReadI16@?$ByteOrderBinaryFileStream@VVAXLittleEndianFormat@btk@@@btk@@UEAAFXZ) _btk C:\Users\fleboeuf\Documents\Programmation\BTK\BUILD btkCore melund\build-python3_0.4.dev0-4-sln\Wrapping\Python\BTKIO.lib(btkC3DFileIO.obj)

repeated for other method of btkC3DFileIO.obj

I am not an expert in c++ compilation and appreciate any help. maybe @chrisdembia, share with us his expertise

regards

Fabien

@melund
Copy link

melund commented Aug 7, 2020

@aaa34169 Did you see how I build it here. Note, the patch I apply. But I guess you get that implicitly by building of the python 3 branch. Though I can't recall it
.

You can try to clone the repository from conda-forge
https://github.com/conda-forge/btk-feedstock
and then run

conda build recipe

It requires that you have a mini-conda installation, the conda-build package installed, a working c compiler (visual studio). But then the script should install the necessary dependencies (cmake,swig, jom) and run the build. Maybe that will help you figure out what is wrong with your build setup.

Why do you want to build it your self?

@aaa34169
Copy link

aaa34169 commented Aug 8, 2020 via email

@jjnurminen
Copy link

@aaa34169 it's probably related to Windows locale or language settings. I'll try to figure it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants