Installation on windows

[AnderBiguri]

It looks like to install meshpy you need a UNIX machine. Is there the possibility of getting a windows supported meshpy release? I am not sure how many things had to be changed, but I think that just taking out the timing (sys/time.h does not exist on windows) may be enough.

I can help with that but I am quite new to python and don't know much about UNIX-WINDOWS differences at this level. I offer my help anyways.

[inducer]

I would love to enable that somehow, but I don't have a Windows development environment available. As such, I can at best help you troubleshoot. Maybe post some errors that you're seeing, and then we can muddle through together?

[liubenyuan]

sure, I want participate too !

[kromar]

not sure if you are looking for a installation package for windows because
this can be found here: http://www.lfd.uci.edu/~gohlke/pythonlibs/#meshpy
if not then just ignore this message

On Sat, Jul 11, 2015 at 2:52 AM, Liu Benyuan [email protected]
wrote:

sure, I want participate too !

—
Reply to this email directly or view it on GitHub
#14 (comment).

[liubenyuan]

@kromar

Hi ! It works !

However, will you compile a newer version of meshpy that supports both max_volume and area constrains ?

i.e., in meshpy\triangle.py, line 152 to 156, and modify them to,

    if volume_constraints:
        opts += "a"

    if max_volume:
        opts += "a%.20f" % max_volume

[inducer]

You'd have to ask Christoph Gohlke that (who maintains those binaries).

[looooo]

I try to set up a conda-package for windows. But I have encountered some problems...(triangle.c need a <sys/time> which is not available on windows) Are there any resources how to build on windows?
@inducer @cgohlke

[inducer]

I don't know much about Windows builds, but I had started a meshpy conda-forge package at a point:

conda-forge/staged-recipes#1480

I've given you access to the source branch in case you would like to use that as the basis for your work.

[looooo]

I didn't know there is already staged-recipe setup. I have setup one for linux some time ago:
https://github.com/booya-at/openglider_conda_recipes/tree/master/meshpy
Recently I have updated to boost 1.64 and also tried to get it running on windows. But this seems a bit more advanced.
The problem with boost 1.64 is that boost-python for py3 is named boost-python3. So I think the script for boost dedection has to be updated: https://github.com/inducer/meshpy/blob/master/aksetup_helper.py#L508
Also I think it's necessary to use a boost version shipped with conda. At least I have encountered problems when mixing boost1.64 and boost1.63 (freecad, meshpy)

[inducer]

Thanks for your work on this. Could you send a pull request?

[looooo]

Once it is working on windows I will try to create a pull request.
On windows the boost-library is called: libboost_python3-vc140-mt-1_64.lib
I don't think the script is able to detect this library?

[looooo]

I tried to find the boost-directories with cmake. But the tests are not working because of some linking problems.
To me the used directories are looking good:

INCLUDE_DIRS:  ['~/conda/conda-bld/meshpy_1498226119091/_b_env_placehold.../include', 'src/cpp']
LIBRARY_DIRS:  ['~/conda/conda-bld/meshpy_1498226119091/_b_env_placehold.../lib']
LIBRARIES:  ['~/conda/conda-bld/meshpy_1498226119091/_b_env_placehold.../lib/libboost_python3.so'] 

The diff can be found here:
looooo@3d54001

[looooo]

after wasting a lot of time, I have made meshpy build on linux with using cmake.
On windows the boost-libraries-dirs should be ok now, but there are some other problems, I do not know how to solve:

wrap_triangle.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""class tFo
reignArray<int> const volatile * __cdecl boost::get_pointer<class tForeignArray<
int> const volatile >(class tForeignArray<int> const volatile *)" (??$get_pointe
r@$$CDV?$tForeignArray@H@@@boost@@YAPEDV?$tForeignArray@H@@PEDV1@@Z)".

maybe @peterlama can help with this. I think we had similar issues with netgen some time ago...

[looooo]

ok I think I have a working windows build.
The workaround is described here: alecthomas/entityx_python#4

@inducer maybe you can have a look if it is possible to merge my changes:
https://github.com/looooo/meshpy/commits/master

After this is done, we can work on the conda-forge recipe. I have uploaded a win-package to https://anaconda.org/OpenGlider/meshpy/files which can be used until the conda-forge package is ready.

[inducer]

Thank you for working on this. Next time, please

• Respect http://pep8.org
• Do not completely destroy the existing configuration scheme. (Your detected config needs to be overridable by the user. Don't blindly overwrite global config just because it works for you.)
• Don't make random assumptions about Py2 libraries being usable for Py3.

Seriously, this took me about 45 minutes to clean up to be even half robust and usable. I appreciate your work, but you've got to be more careful. See 58db625 for my changes.

[looooo]

thanks for merging this into this branch. I know some things were not perfect yet, and this is because I did not understand your build fully... It was only an idea to find boost-python with cmake. At the beginning I wasn't sure if this will work, so I simple tried it step by step. And my branch was the result of this. So not very clean. I just wanted to make sure my way of handling the boost dependencies is the way to proceed. For a PR I would have cleaned the branch.
But thanks for this effort. I appreciate that.

I do not understand your 3rd point . Is this about the cmake?
Not every boost-python for python3 is named boost-python3. the additional number (3) is added in boost version 1.64. So for older version we also have to look for a boost-python...

[inducer]

Not every boost-python for python3 is named boost-python3. the additional number (3) is added in boost version 1.64. So for older version we also have to look for a boost-python...

Hmm. Unfortunately (as I learned on my own machine), this cuts both ways. Python 3 will happily link against the Py2 Boost.Python library, and once imported, the resulting module will crash the interpreter without a meaningful message. My vote would be to restrict to the python3 library name to avoid that type of disaster.

[looooo]

You can also check the boost version and support python3 only if it is higher than 1.64. Boost-python is anyway a quite difficult dependency. Have you ever thought about updating to pybind11? It's header only, and therefore not problematic regarding version mismatch.

[inducer]

I would like that, but I don't have the time to do it at the moment.