PR#14: Fix build with lib3mf 2.2.0 - rpms/openscad

rpms / openscad

#14 Fix build with lib3mf 2.2.0

Closed 2 years ago by churchyard. Opened 2 years ago by lbalhar.

rpms/ lbalhar/openscad rawhide into rawhide

Fix build with lib3mf 2.2.0

Lumir Balhar • 2 years ago

659e92e

openscad.spec

file modified

+8 -2

		`@@ -1,7 +1,7 @@`
		`Name: openscad`
		`Version: 2021.01`
		`%global upversion %{version}`
		`- Release: 8%{?dist}`
		`+ Release: 9%{?dist}`
		`Summary: The Programmers Solid 3D CAD Modeller`
		`# COPYING contains a linking exception for CGAL`
		`# Appdata file is CC0`
		`@@ -174,7 +174,10 @@`
		`sed -i 's@MCAD/__init__.py@MCAD/gears.scad@' tests/CMakeLists.txt`

		`%build`
		`- %{qmake_qt5} PREFIX=%{_prefix} VERSION=%{upversion} CONFIG-=debug`
		`+ # qmake tries to detect version of lib3mf by looking for lib3mf_implicit.hpp`
		`+ # see https://github.com/openscad/openscad/blob/openscad-2021.01/features/lib3mf.prf#L40`
		`+ # but that file is in different location in Fedora.`
		`+ %{qmake_qt5} LIB3MF_INCLUDEPATH=/usr/include/lib3mf/Bindings/Cpp PREFIX=%{_prefix} VERSION=%{upversion} CONFIG-=debug`
		`%make_build`

		`# tests`
		`@@ -227,6 +230,9 @@`
		`%{_datadir}/%{name}/libraries/MCAD/bitmap/*.scad`

		`%changelog`
		`+ * Wed Apr 06 2022 Lumír Balhar <lbalhar@redhat.com> - 2021.01-9`
		`+ - Fix build with lib3mf 2.2.0`
		`+`
		`* Tue Apr 05 2022 Lumír Balhar <lbalhar@redhat.com> - 2021.01-8`
		`- Security fixes for CVE-2022-0496 and CVE-2022-0497`
		`- Fixes: rhbz#2050696 rhbz#2050700`

lbalhar commented 2 years ago

This fixes the build with lib3mf 2.2.0. See: https://copr.fedorainfracloud.org/coprs/lbalhar/openscad/build/4084851/

This is just a workaround. If qmake does not find lib3mf it disables its support so this hack is enough because cmake has its own logic to find the library when compiling. Support for qmake is removed upstream and a lot of files changed their locations so it's not easy to backport more possibly useful patches.

There is still one failing test with 3mf in the name - 3mfexport_3mf-export - but I've tested importing and exporting 3mf files in a headless environment and it works fine. I'm not able to test this on my machine without building this for Fedora 35.

churchyard commented 2 years ago

Thanks. Curious questions:

Does LIB3MF_INCLUDEPATH need to be an environment variable, or can it be passed to qmake as is e.g. PREFIX?
Does this still work with the previous lib3mf version?
Can we symlink the header file in lib3mf to the previous location to make it backward-compatible instead?

lbalhar commented 2 years ago

Thanks. Curious questions:

Does LIB3MF_INCLUDEPATH need to be an environment variable, or can it be passed to qmake as is e.g. PREFIX?

fixed

Does this still work with the previous lib3mf version?

Yes, tested as well in the headless env. I mean I had the new fixed openscad with the old lib3mf from rawhide. I think this change has only a build-time impact and only for qmake.

Can we symlink the header file in lib3mf to the previous location to make it backward-compatible instead?

This is a workaround for openscad and it's only temporary because the next release won't use qmake anymore so I'd keep it here.

rebased onto 659e92e

2 years ago

churchyard commented 2 years ago

I see Project MESSAGE: 3MF Import/Export disabled in the build log of the scratch build here. Hence this does not work with the previous version of lib3mf.

lbalhar commented 2 years ago

I see Project MESSAGE: 3MF Import/Export disabled in the build log of the scratch build here. Hence this does not work with the previous version of lib3mf.

It does when the openscad is built with lib3mf 2.2 and it's installed with older lib3mf 2.0. I can add buildrequire for lb3mf >= 2.2.0 if you don't plan to update lib3mf in beta and stable releases.

churchyard commented 2 years ago

Well, the difference between the old and new lib3mf-devel package is (more or less):

diff -u <(rpm -qlp lib3mf-devel-2.0.1-3.fc36.x86_64.rpm) <(rpm -qlp lib3mf-devel-2.2.0-1.fc37.x86_64.rpm)
...
-/usr/include/lib3mf/lib3mf.h
-/usr/include/lib3mf/lib3mf_abi.hpp
-/usr/include/lib3mf/lib3mf_dynamic.h
-/usr/include/lib3mf/lib3mf_dynamic.hpp
-/usr/include/lib3mf/lib3mf_implicit.hpp
-/usr/include/lib3mf/lib3mf_nodewrapper.h
-/usr/include/lib3mf/lib3mf_types.h
-/usr/include/lib3mf/lib3mf_types.hpp
...

I belive I can fix that in lib3mf and if I do, we don't need this hack, correct?

lbalhar commented 2 years ago

Ok, why not.

churchyard commented 2 years ago

Pushed to https://src.fedoraproject.org/rpms/lib3mf/pull-request/2 and testing in https://copr.fedorainfracloud.org/coprs/churchyard/lib3mf-2.2.0/builds/

If everything goes well, we can close this, as no changes will be required in OpenSCAD, but this PR made me realize what's needed, thanks for that!