Discussion:
[OpenSCAD] AMF import on Windows doesn't work.
nop head
2018-08-30 12:42:41 UTC
Permalink
All the test that import AMF fail for me on Windows.

Is this supposed to be working or is there an open issue for it?
Marius Kintel
2018-08-30 13:21:46 UTC
Permalink
Post by nop head
All the test that import AMF fail for me on Windows.
Is this supposed to be working or is there an open issue for it?
To my knowledge it’s supposed to work, but it’s not a very widely used feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.

-Marius
nop head
2018-08-30 14:22:48 UTC
Permalink
It does nothing silently. Under MSYS2 I think it is a build problem because
qmake cant find libzip but I tested it with the Windows snapshot and that
doesn't work either.
I will look into it.

So does nobody use AMF and Windows?

Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable
Post by nop head
All the test that import AMF fail for me on Windows.
Is this supposed to be working or is there an open issue for it?
To my knowledge it’s supposed to work, but it’s not a very widely used
feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.
-Marius
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Marius Kintel
2018-08-30 14:31:24 UTC
Permalink
It's entirely possible that we're ignoring a build error for the snapshot
as well; we don't have an automated test pipeline set up for Windows as we
do on the other platforms.

I'd wager that virtually nobody uses AMF at all - that standard doesn't
seem to be going anywhere : /

-Marius
Post by nop head
It does nothing silently. Under MSYS2 I think it is a build problem
because qmake cant find libzip but I tested it with the Windows snapshot
and that doesn't work either.
I will look into it.
So does nobody use AMF and Windows?
Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable
Post by nop head
All the test that import AMF fail for me on Windows.
Is this supposed to be working or is there an open issue for it?
To my knowledge it’s supposed to work, but it’s not a very widely used
feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.
-Marius
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
doug moen
2018-08-30 15:17:30 UTC
Permalink
Cura removed AMF support in 2016, at the same time that they added 3MF
support.
Various reasons were given for removing AMF support:
* nobody uses it
* the standard contradicts itself
* it is not an open standard (ie, devs need to pay money for a copy of the
standard, no sharing)
Post by Marius Kintel
It's entirely possible that we're ignoring a build error for the snapshot
as well; we don't have an automated test pipeline set up for Windows as we
do on the other platforms.
I'd wager that virtually nobody uses AMF at all - that standard doesn't
seem to be going anywhere : /
-Marius
Post by nop head
It does nothing silently. Under MSYS2 I think it is a build problem
because qmake cant find libzip but I tested it with the Windows snapshot
and that doesn't work either.
I will look into it.
So does nobody use AMF and Windows?
Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable
Post by nop head
All the test that import AMF fail for me on Windows.
Is this supposed to be working or is there an open issue for it?
To my knowledge it’s supposed to work, but it’s not a very widely used
feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.
-Marius
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-08-30 16:31:46 UTC
Permalink
The test suit seems to use it as a means to an end, rather than just
testing AMF.

$ ctest -R cube
running 'C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe
--info' to generate sysinfo.txt
Post test:C:/msys64/mingw64/bin/python.exe
"C:/msys64/home/ChrisP/openscad/tests/test_pretty_print.py"
--builddir=C:/msys64/home/ChrisP/openscad/tests
Test project C:/msys64/home/ChrisP/openscad/tests
Enforcing Default test configuration. Use ctest -C <config> to override
Start 132: dumptest_cube-tests
1/14 Test #132: dumptest_cube-tests ................. Passed 0.29 sec
Start 209: dumptest-examples_text_on_cube
2/14 Test #209: dumptest-examples_text_on_cube ...... Passed 0.28 sec
Start 303: cgalpngtest_cube-tests
3/14 Test #303: cgalpngtest_cube-tests .............. Passed 1.00 sec
Start 339: cgalpngtest_cube-with-hole
4/14 Test #339: cgalpngtest_cube-with-hole ..........***Failed 0.65 sec
Start 466: opencsgtest_cube-tests
5/14 Test #466: opencsgtest_cube-tests .............. Passed 0.64 sec
Start 516: opencsgtest_cube-with-hole
6/14 Test #516: opencsgtest_cube-with-hole ..........***Failed 0.70 sec
Start 643: csgpngtest_cube-tests
7/14 Test #643: csgpngtest_cube-tests ............... Passed 1.04 sec
Start 680: csgpngtest_cube-with-hole
8/14 Test #680: csgpngtest_cube-with-hole ...........***Failed 0.94 sec
Start 807: throwntogethertest_cube-tests
9/14 Test #807: throwntogethertest_cube-tests ....... Passed 0.69 sec
Start 855: throwntogethertest_cube-with-hole
10/14 Test #855: throwntogethertest_cube-with-hole ...***Failed 0.64 sec
Start 918: monotonepngtest_cube10
11/14 Test #918: monotonepngtest_cube10 .............. Passed 0.65 sec
Start 919: stlpngtest_cube10
12/14 Test #919: stlpngtest_cube10 ................... Passed 0.96 sec
Start 920: offpngtest_cube10
13/14 Test #920: offpngtest_cube10 ................... Passed 0.93 sec
Start 921: amfpngtest_cube10
14/14 Test #921: amfpngtest_cube10 ...................***Failed 0.94 sec

64% tests passed, 5 tests failed out of 14

Total Test time (real) = 10.56 sec

The following tests FAILED:
339 - cgalpngtest_cube-with-hole (Failed)
516 - opencsgtest_cube-with-hole (Failed)
680 - csgpngtest_cube-with-hole (Failed)
855 - throwntogethertest_cube-with-hole (Failed)
921 - amfpngtest_cube10 (Failed)
Post by doug moen
Cura removed AMF support in 2016, at the same time that they added 3MF
support.
* nobody uses it
* the standard contradicts itself
* it is not an open standard (ie, devs need to pay money for a copy of the
standard, no sharing)
Post by Marius Kintel
It's entirely possible that we're ignoring a build error for the snapshot
as well; we don't have an automated test pipeline set up for Windows as we
do on the other platforms.
I'd wager that virtually nobody uses AMF at all - that standard doesn't
seem to be going anywhere : /
-Marius
Post by nop head
It does nothing silently. Under MSYS2 I think it is a build problem
because qmake cant find libzip but I tested it with the Windows snapshot
and that doesn't work either.
I will look into it.
So does nobody use AMF and Windows?
Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable
Post by nop head
All the test that import AMF fail for me on Windows.
Is this supposed to be working or is there an open issue for it?
To my knowledge it’s supposed to work, but it’s not a very widely used
feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.
-Marius
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-08-30 16:50:15 UTC
Permalink
Without libzip the AMF importer falls back to only being able to read non
zipped AMF files.
cube-with-hole.amf is XML, so it should be able to read it without libzip.
More investigation required.
Post by nop head
The test suit seems to use it as a means to an end, rather than just
testing AMF.
$ ctest -R cube
running 'C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe
--info' to generate sysinfo.txt
Post test:C:/msys64/mingw64/bin/python.exe "C:/msys64/home/ChrisP/
openscad/tests/test_pretty_print.py" --builddir=C:/msys64/home/
ChrisP/openscad/tests
Test project C:/msys64/home/ChrisP/openscad/tests
Enforcing Default test configuration. Use ctest -C <config> to override
Start 132: dumptest_cube-tests
1/14 Test #132: dumptest_cube-tests ................. Passed 0.29 sec
Start 209: dumptest-examples_text_on_cube
2/14 Test #209: dumptest-examples_text_on_cube ...... Passed 0.28 sec
Start 303: cgalpngtest_cube-tests
3/14 Test #303: cgalpngtest_cube-tests .............. Passed 1.00 sec
Start 339: cgalpngtest_cube-with-hole
4/14 Test #339: cgalpngtest_cube-with-hole ..........***Failed 0.65 sec
Start 466: opencsgtest_cube-tests
5/14 Test #466: opencsgtest_cube-tests .............. Passed 0.64 sec
Start 516: opencsgtest_cube-with-hole
6/14 Test #516: opencsgtest_cube-with-hole ..........***Failed 0.70 sec
Start 643: csgpngtest_cube-tests
7/14 Test #643: csgpngtest_cube-tests ............... Passed 1.04 sec
Start 680: csgpngtest_cube-with-hole
8/14 Test #680: csgpngtest_cube-with-hole ...........***Failed 0.94 sec
Start 807: throwntogethertest_cube-tests
9/14 Test #807: throwntogethertest_cube-tests ....... Passed 0.69 sec
Start 855: throwntogethertest_cube-with-hole
10/14 Test #855: throwntogethertest_cube-with-hole ...***Failed 0.64 sec
Start 918: monotonepngtest_cube10
11/14 Test #918: monotonepngtest_cube10 .............. Passed 0.65 sec
Start 919: stlpngtest_cube10
12/14 Test #919: stlpngtest_cube10 ................... Passed 0.96 sec
Start 920: offpngtest_cube10
13/14 Test #920: offpngtest_cube10 ................... Passed 0.93 sec
Start 921: amfpngtest_cube10
14/14 Test #921: amfpngtest_cube10 ...................***Failed 0.94 sec
64% tests passed, 5 tests failed out of 14
Total Test time (real) = 10.56 sec
339 - cgalpngtest_cube-with-hole (Failed)
516 - opencsgtest_cube-with-hole (Failed)
680 - csgpngtest_cube-with-hole (Failed)
855 - throwntogethertest_cube-with-hole (Failed)
921 - amfpngtest_cube10 (Failed)
Post by doug moen
Cura removed AMF support in 2016, at the same time that they added 3MF
support.
* nobody uses it
* the standard contradicts itself
* it is not an open standard (ie, devs need to pay money for a copy of
the standard, no sharing)
Post by Marius Kintel
It's entirely possible that we're ignoring a build error for the
snapshot as well; we don't have an automated test pipeline set up for
Windows as we do on the other platforms.
I'd wager that virtually nobody uses AMF at all - that standard doesn't
seem to be going anywhere : /
-Marius
Post by nop head
It does nothing silently. Under MSYS2 I think it is a build problem
because qmake cant find libzip but I tested it with the Windows snapshot
and that doesn't work either.
I will look into it.
So does nobody use AMF and Windows?
Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable
Post by nop head
All the test that import AMF fail for me on Windows.
Is this supposed to be working or is there an open issue for it?
To my knowledge it’s supposed to work, but it’s not a very widely used
feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.
-Marius
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-08-30 23:34:12 UTC
Permalink
The reason it does not work on Windows is the AMF parser uses fs::path to
represent element hierarchies in the XML file, for example
/amf/object/mesh/volume/triangle. 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.
Post by nop head
Without libzip the AMF importer falls back to only being able to read non
zipped AMF files.
cube-with-hole.amf is XML, so it should be able to read it without libzip.
More investigation required.
Post by nop head
The test suit seems to use it as a means to an end, rather than just
testing AMF.
$ ctest -R cube
running 'C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe
--info' to generate sysinfo.txt
Post test:C:/msys64/mingw64/bin/python.exe "C:/msys64/home/ChrisP/openscad/tests/test_pretty_print.py"
--builddir=C:/msys64/home/ChrisP/openscad/tests
Test project C:/msys64/home/ChrisP/openscad/tests
Enforcing Default test configuration. Use ctest -C <config> to override
Start 132: dumptest_cube-tests
1/14 Test #132: dumptest_cube-tests ................. Passed 0.29 sec
Start 209: dumptest-examples_text_on_cube
2/14 Test #209: dumptest-examples_text_on_cube ...... Passed 0.28 sec
Start 303: cgalpngtest_cube-tests
3/14 Test #303: cgalpngtest_cube-tests .............. Passed 1.00 sec
Start 339: cgalpngtest_cube-with-hole
4/14 Test #339: cgalpngtest_cube-with-hole ..........***Failed 0.65 sec
Start 466: opencsgtest_cube-tests
5/14 Test #466: opencsgtest_cube-tests .............. Passed 0.64 sec
Start 516: opencsgtest_cube-with-hole
6/14 Test #516: opencsgtest_cube-with-hole ..........***Failed 0.70 sec
Start 643: csgpngtest_cube-tests
7/14 Test #643: csgpngtest_cube-tests ............... Passed 1.04 sec
Start 680: csgpngtest_cube-with-hole
8/14 Test #680: csgpngtest_cube-with-hole ...........***Failed 0.94 sec
Start 807: throwntogethertest_cube-tests
9/14 Test #807: throwntogethertest_cube-tests ....... Passed 0.69 sec
Start 855: throwntogethertest_cube-with-hole
10/14 Test #855: throwntogethertest_cube-with-hole ...***Failed 0.64 sec
Start 918: monotonepngtest_cube10
11/14 Test #918: monotonepngtest_cube10 .............. Passed 0.65 sec
Start 919: stlpngtest_cube10
12/14 Test #919: stlpngtest_cube10 ................... Passed 0.96 sec
Start 920: offpngtest_cube10
13/14 Test #920: offpngtest_cube10 ................... Passed 0.93 sec
Start 921: amfpngtest_cube10
14/14 Test #921: amfpngtest_cube10 ...................***Failed 0.94 sec
64% tests passed, 5 tests failed out of 14
Total Test time (real) = 10.56 sec
339 - cgalpngtest_cube-with-hole (Failed)
516 - opencsgtest_cube-with-hole (Failed)
680 - csgpngtest_cube-with-hole (Failed)
855 - throwntogethertest_cube-with-hole (Failed)
921 - amfpngtest_cube10 (Failed)
Post by doug moen
Cura removed AMF support in 2016, at the same time that they added 3MF
support.
* nobody uses it
* the standard contradicts itself
* it is not an open standard (ie, devs need to pay money for a copy of
the standard, no sharing)
Post by Marius Kintel
It's entirely possible that we're ignoring a build error for the
snapshot as well; we don't have an automated test pipeline set up for
Windows as we do on the other platforms.
I'd wager that virtually nobody uses AMF at all - that standard doesn't
seem to be going anywhere : /
-Marius
Post by nop head
It does nothing silently. Under MSYS2 I think it is a build problem
because qmake cant find libzip but I tested it with the Windows snapshot
and that doesn't work either.
I will look into it.
So does nobody use AMF and Windows?
Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable
Post by nop head
All the test that import AMF fail for me on Windows.
Is this supposed to be working or is there an open issue for it?
To my knowledge it’s supposed to work, but it’s not a very widely
used feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.
-Marius
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Torsten Paul
2018-08-31 00:12:28 UTC
Permalink
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.
nop head
2018-08-31 06:37:31 UTC
Permalink
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.
Post by Torsten Paul
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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-08-31 08:52:51 UTC
Permalink
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?
Post by nop head
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.
Post by Torsten Paul
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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Torsten Paul
2018-08-31 10:06:47 UTC
Permalink
Post by nop head
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.
nop head
2018-08-31 10:36:13 UTC
Permalink
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
Post by Torsten Paul
Post by nop head
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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-08-31 11:11:09 UTC
Permalink
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.
Post by nop head
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
https://github.com/openscad/openscad/issues/1919
Post by Torsten Paul
Post by nop head
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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-08-31 12:17:56 UTC
Permalink
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)
Post by nop head
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.
Post by nop head
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
https://github.com/openscad/openscad/issues/1919
Post by Torsten Paul
Post by nop head
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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Torsten Paul
2018-08-31 21:04:47 UTC
Permalink
Post by nop head
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.
Post by nop head
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.
Post by nop head
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.
Post by nop head
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.

Loading...