[2.1] - Multi-architecture installation not possible anymore

[thopiekar]

Because debian allows multiarch installation of libraries, it is needed to install to a specific path.
CMAKE_LIBRARY_PATH usually sets this path, but it doesn't work anymore on 15.10 branch.
The reason could be commit 6eeb674 here the */lib path has been hardcoded.

Install the project...
/usr/bin/cmake -P cmake_install.cmake
-- Install configuration: "None"
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/libArcus.so.15.09.81
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/libArcus.so.1
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/libArcus.so
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/include/Arcus/Socket.h
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/include/Arcus/SocketListener.h
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/include/Arcus/Types.h
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/include/Arcus/ArcusExport.h
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/cmake/Arcus/Arcus-targets.cmake
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/cmake/Arcus/Arcus-targets-none.cmake
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/cmake/Arcus/ArcusConfig.cmake
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/cmake/Arcus/ArcusConfigVersion.cmake
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/python3/dist-packages/Arcus/__init__.py
make[1]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu'
    cd /«PKGBUILDDIR»
   debian/rules override_dh_install
make[1]: Entering directory '/«PKGBUILDDIR»'
dh_install --fail-missing
dh_install: libarcus missing files (/usr/lib/*/libArcus.so.*), aborting
debian/rules:10: recipe for target 'override_dh_install' failed

On master it is working with:

Install the project...
/usr/bin/cmake -P cmake_install.cmake
-- Install configuration: "None"
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/x86_64-linux-gnu/libArcus.so.15.05.90
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/x86_64-linux-gnu/libArcus.so.1
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/x86_64-linux-gnu/libArcus.so
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/include/Arcus/Socket.h
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/include/Arcus/SocketListener.h
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/include/Arcus/Types.h
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/include/Arcus/ArcusExport.h
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/Arcus/Arcus-targets.cmake
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/Arcus/Arcus-targets-none.cmake
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/Arcus/ArcusConfig.cmake
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/Arcus/ArcusConfigVersion.cmake
-- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/python3/dist-packages/Arcus/__init__.py

[awhiemstra]

As you might have guessed, since this is still open, this is a tricky issue. I do not currently have a proper solution, though adding a cached path for library installation might work. Is there a document somewhere that indicates what should go where on Debian?

[thopiekar]

Well, I think you don't have to look for a Debian specific solution. There are CMake variables which are already defined by default for any platform. In case of Debian packaging they are just overwritten by a prefix just before it gets packaged. It should be variables like DESTDIR, LIBDIR or BINDIR from autotools. Hope it helps a little bit.

[thopiekar]

Hey,
it's been a long while since we were discussing about this problem. So back to commit 6eeb674
When does it happen so this kind of hardcoding is needed. I guess you use some kind of a script building your cura bundles. Isn't it posssile to run CMAKE_INSTALL_BINDIR=bin CMAKE_INSTALL_LIBDIR=lib CMAKE_INSTALL_INCLUDEDIR=include cmake . in your scripts? Is there a way to reproduce it here? Maybe someone else or me is interested and has got time to find a more elegant fix fo this.

Regards

[thopiekar]

Any updates or news on this?

PS: I just created #21 and #22 to revert this.

[tomboy-64]

Hardcoding install dirs is never a good idea; this effectively breaks your system's interoperability with automated build-systems downstream.
You mentioned this being a tricky issue? Maybe we could help?

[thopiekar]

@tomboy-64 I already made reverts on this change and made tests on it. Currently it works on Ubuntu without hardcodes and the real problem was caused while using ArchLinux. However you can read yourself the whole story in the PR made for [master]. I guess they are really busy at the moment.

[nallath]

We're always busy ;) But yeah, releasing 2.1 did put a lot of pressure on the team (multiple delays & all). Things are a bit more relaxed now, but working at ultimaker is never calm or quiet ;)

Another issue is that i know very little of build systems (Which is also why I'm damn happy that you guys pick these things up :D). Same goes for GhostKeeper, so most of these issues are left to awhiemstra and he doesn't check github as often as me & ghostkeeper do.

[thopiekar]

Ah, OK. Well, I would prepare in your case chroots for every distribution you are targeting. For example you take one folder for all the sources and then share it between all the chroots. I'm just to lazy at the moment to set this up and I actually won't need this so often as you probably do. Looks like Ultimaker needs a Linux hacker in their team 😁

[nallath]

So uh, looking for a job then?

[thopiekar]

Yes and it sounds interesting to work for you. At least I would get paid for fixing problems in applications or their packaging 😉

I made this for years across different opensource projects and gave projects, like kivy (https://kivy.org/#aboutus), the possibility to be easier to setup and access.
Another project is PySide2 (alternative to PyQt5), which is currently not stable and fully functional, where I provide packages for it in a PPA and give other projects, like ROS (www.ros.org), again easier access to nightly builds.

If you think I made a good job so far and I would fit into the team, I can write your supervisor about myself or, if you like, you can ask yourself if there is a free job for me 😃

[BagelOrb]

There's always a job opening in our team!
You could write to r.becker[at]ultimaker.com who is currently in charge of
job applications, but you could include j.vankessel[at]ultimaker.com to be
sure you don't end up on the wrong pile ;)

Our team is looking forward to meeting you ^^
Op 15 apr. 2016 19:04 schreef "Thomas Karl Pietrowski" <
notifications@github.com>:

Yes and it sounds interesting to work for you. At least I would get paid
for fixing problems in applications or their packaging [image: 😉]

I made this for years across different opensource projects and gave
projects, like kivy (https://kivy.org/#aboutus), the possibility to be
easier to setup and access.
Another project is PySide2 (alternative to PyQt5), which is currently not
stable and fully functional, where I provide packages for it in a PPA and
give other projects, like ROS (www.ros.org), again easier access to
nightly builds.

If you think I made a good job so far and I would fit into the team, I can
write your supervisor about myself or, if you like, you can ask yourself if
there is a free job for me [image: 😃]

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#10 (comment)

[thopiekar]

@BagelOrb Thank you! I always love to hear you like my work 😄
Now I just wrote a mail to Mr. Becker and CC'd @nallath. I introduced myself, wrote about my ideas and motivation to work with you. Hope they will be satisfied with it. (fingers crossed)

[fieldOfView]

Awesome!