AMF import on Windows doesn't work.
Using a std::string works and now all the non-zipped AMF tests pass.
How does libzip get incorporated on Linux and why is it missing on Windows?
Obviously I can download it manually but where should I put it and why
isn't it done automatically?
On 31 August 2018 at 07:37, nop head nop.head@gmail.com wrote:
Yes I will change it to a string as it isn't a file system path, so using
fs::path also makes the code a bit confusing.
On 31 August 2018 at 01:12, Torsten Paul Torsten.Paul@gmx.de wrote:
On 08/31/2018 01:34 AM, nop head wrote:
On Windows fs:path uses \ instead of / so the paths don't match those
in the maps of functions. So no functions are called and and empty
polyset is returned.
Oh, so instead of path.string() it should be path.generic_string()?
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 08/31/2018 10:52 AM, nop head wrote:
How does libzip get incorporated on Linux and why is it missing on
Windows? Obviously I can download it manually but where should I put
it and why isn't it done automatically?
It's supposed to be included via pkg-config, there was some discussion
in https://github.com/openscad/openscad/issues/2441 too. There were
quite some changes to the MXE build, thanks to Tony from the MXE team
who helped to bring the build to gcc7 (mxe-gcc7 branch).
I guess the answer to why it's broken is that multi-platform builds
are hard but the problem is only seen by people actually giving it
a try ;-). I would have expected libzip to work without too much
issues on MSYS2 though as it's much closer to Linux builds as MXE is.
ciao,
Torsten.
Yes I saw that but it is about bzip2 rather than libzip. Does MXE use bzip2
instead of libzip or are both required?
pkg-config seems to expect the package to be already there rather than
being responsible for downloading it. Is it already there on Linux?
The magic incantation on MSYS2 seems to be pacman -S
mingw-w64-x86_64-libzip. That gets to this problem:
https://github.com/openscad/openscad/issues/1919
On 31 August 2018 at 11:06, Torsten Paul Torsten.Paul@gmx.de wrote:
On 08/31/2018 10:52 AM, nop head wrote:
How does libzip get incorporated on Linux and why is it missing on
Windows? Obviously I can download it manually but where should I put
it and why isn't it done automatically?
It's supposed to be included via pkg-config, there was some discussion
in https://github.com/openscad/openscad/issues/2441 too. There were
quite some changes to the MXE build, thanks to Tony from the MXE team
who helped to bring the build to gcc7 (mxe-gcc7 branch).
I guess the answer to why it's broken is that multi-platform builds
are hard but the problem is only seen by people actually giving it
a try ;-). I would have expected libzip to work without too much
issues on MSYS2 though as it's much closer to Linux builds as MXE is.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
This seems to be another incorrect use of boost::filesystem::path for the
filename. The filename is internal to the ZIP file, so presumably its
format should be independent of the OS. It looks like filesystem::path is
only used to separate the filename from the rest of the path but it has the
unintended consequence of converting it to wide characters on Windows.
There is the wider problem of what happens if the path is utf8, but that
depends on libxml2 and libzip in this case but is generally broken on
Windows in other places anyway.
I am minded to use a std:string again and manually isolate the filename to
locate the file in the archive.
On 31 August 2018 at 11:36, nop head nop.head@gmail.com wrote:
Yes I saw that but it is about bzip2 rather than libzip. Does MXE use
bzip2 instead of libzip or are both required?
pkg-config seems to expect the package to be already there rather than
being responsible for downloading it. Is it already there on Linux?
The magic incantation on MSYS2 seems to be pacman -S
mingw-w64-x86_64-libzip. That gets to this problem:
https://github.com/openscad/openscad/issues/1919
On 31 August 2018 at 11:06, Torsten Paul Torsten.Paul@gmx.de wrote:
On 08/31/2018 10:52 AM, nop head wrote:
How does libzip get incorporated on Linux and why is it missing on
Windows? Obviously I can download it manually but where should I put
it and why isn't it done automatically?
It's supposed to be included via pkg-config, there was some discussion
in https://github.com/openscad/openscad/issues/2441 too. There were
quite some changes to the MXE build, thanks to Tony from the MXE team
who helped to bring the build to gcc7 (mxe-gcc7 branch).
I guess the answer to why it's broken is that multi-platform builds
are hard but the problem is only seen by people actually giving it
a try ;-). I would have expected libzip to work without too much
issues on MSYS2 though as it's much closer to Linux builds as MXE is.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Did it the old fashioned way with char*s. All the AMF tests now pass on
Windows with my two PRs https://github.com/openscad/openscad/pull/2467 and
https://github.com/openscad/openscad/pull/2471.
Only four of the default tests fail on Windows now. Three are differences
in Z fighting so I think that is just a difference in graphics cards, not
actual errors.
The only real error is the test for non-ascii characters.
99% tests passed, 4 tests failed out of 1126
Total Test time (real) = 946.92 sec
The following tests FAILED:
533 - opencsgtest_issue1165 (Failed)
536 - opencsgtest_issue1215 (Failed)
875 - throwntogethertest_issue1215 (Failed)
1105 - openscad-nonascii_sfære (Failed)
On 31 August 2018 at 12:11, nop head nop.head@gmail.com wrote:
This seems to be another incorrect use of boost::filesystem::path for the
filename. The filename is internal to the ZIP file, so presumably its
format should be independent of the OS. It looks like filesystem::path is
only used to separate the filename from the rest of the path but it has the
unintended consequence of converting it to wide characters on Windows.
There is the wider problem of what happens if the path is utf8, but that
depends on libxml2 and libzip in this case but is generally broken on
Windows in other places anyway.
I am minded to use a std:string again and manually isolate the filename to
locate the file in the archive.
On 31 August 2018 at 11:36, nop head nop.head@gmail.com wrote:
Yes I saw that but it is about bzip2 rather than libzip. Does MXE use
bzip2 instead of libzip or are both required?
pkg-config seems to expect the package to be already there rather than
being responsible for downloading it. Is it already there on Linux?
The magic incantation on MSYS2 seems to be pacman -S
mingw-w64-x86_64-libzip. That gets to this problem:
https://github.com/openscad/openscad/issues/1919
On 31 August 2018 at 11:06, Torsten Paul Torsten.Paul@gmx.de wrote:
On 08/31/2018 10:52 AM, nop head wrote:
How does libzip get incorporated on Linux and why is it missing on
Windows? Obviously I can download it manually but where should I put
it and why isn't it done automatically?
It's supposed to be included via pkg-config, there was some discussion
in https://github.com/openscad/openscad/issues/2441 too. There were
quite some changes to the MXE build, thanks to Tony from the MXE team
who helped to bring the build to gcc7 (mxe-gcc7 branch).
I guess the answer to why it's broken is that multi-platform builds
are hard but the problem is only seen by people actually giving it
a try ;-). I would have expected libzip to work without too much
issues on MSYS2 though as it's much closer to Linux builds as MXE is.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 08/31/2018 12:36 PM, nop head wrote:
Yes I saw that but it is about bzip2 rather than libzip.
Does MXE use bzip2 instead of libzip or are both required?
No, the OP was about bzip2, but somewhere in the discussion
Tony mentioned that PKGCONFIG+=libzip did make it work.
pkg-config seems to expect the package to be already there
rather than being responsible for downloading it. Is it
already there on Linux?
The (dev-)package needs to be installed, pkg-config will just
use the *.pc files that were installed along with the packages
to provide the various options.
There is the wider problem of what happens if the path is
utf8, but that depends on libxml2 and libzip in this case
but is generally broken on Windows in other places anyway.
Thanks for diving into that issue, this helps a lot as most
of the time we seem to have no developer with Windows env
so this type of problems are detected quite late.
Only four of the default tests fail on Windows now. Three
are differences in Z fighting so I think that is just a
difference in graphics cards, not actual errors.
The only real error is the test for non-ascii characters.
99% tests passed, 4 tests failed out of 1126
Yes, those Z-fighting issues are disabled on Travis too.
I'm not sure why they are in the normal test list.
ciao,
Torsten.