Symlink to deps - is it stupid?

sum01 · 2017-07-03 22:19:31

So I have this pkgbuild https://aur.archlinux.org/packages/vcash/ where I'm just pulling source files for the deps, building them, and putting them into the actual pkg's folders. I know this isn't ideal, but at the moment there isn't a make/cmake, and I was following the https://github.com/openvcash/vcash-scripts for reference on getting the pkgbuild to work.

So I was thinking that I might be able to at least not pull openssl & boost, but instead add them as deps, and create a bunch of symlinks inside of the source's expected deps folders.
For example, I could add...

depends=('openssl-1.0=1.0.2.k' 'boost=1.53.0')

and then add a ton of symlinks to the expected files inside of the $srcdir/$pkgname/src/deps/openssl and $srcdir/$pkgname/src/deps/boost

I couldn't really do this for db though, as they don't have db=6.1.29.NC in the repo's, and the AUR only has db6.2.

But anyways, would this be stupid?

FlowIt · 2017-07-03 23:50:20

I won't say it's stupid, but it's definitely ugly. There is a pull request for adding CMake build support which will greatly simplify your PKGBUILD. Although it looks like there are still some bugs to fix in this PR. If you know CMake my advice would be to take this PR, fix it and ultimately use it. As for openssl and boost: The existing build script statically links those (which I consider a stupid idea...) to adding them to your depends would actually be wrong. The PR dynamically links those, then you have to add them to your depends (and you also don't have to build them).
I can't think of a single reason why you (as a packager - not upstream) should build the package itself AND its dependencies together.

sum01 · 2017-07-04 00:09:00

I've seen that PR, but the problem is I don't know the first bit about implementing cmake. Although I think a dev said he was working on the OSX cmake, so I assume I could tweak that a little to make it work on Linux, once it's pushed anyways.

So would you recommend I go the symlink route, at least till cmake is added to the code base?

Trilby · 2017-07-04 00:37:01

Why not work with the build system currently in place. The project includes jamfiles for use with boost's b2.

You can patch a couple jamfiles to use the system libraries rather than the project relative libraries.

sum01 · 2017-07-04 01:15:12

Didn't know about those, reading up on it now.

sum01 · 2017-07-06 01:42:12

So I'm sure it's something simple, but I don't seem to have a bootstrap.jam file after installing boost with pacman.

I've set the boost-build.jam to check build-system instead of a folder path, but it just tells me it couldn't find bootstrap.jam in my BOOST_BUILD_PATH.

Is there a package I'm missing? I've been looking at the tutorial and it doesn't mention creation of the bootstrap.jam, it seems to just assume you should have it.

Log

Unable to load Boost.Build: could not find build system.
---------------------------------------------------------
~/vcash-test/src/vcash/src/coin/test/boost-build.jam attempted to load the build system by invoking

   'boost-build build-system ;'

but we were unable to find "bootstrap.jam" in the specified directory
or in BOOST_BUILD_PATH (searching ~/vcash-test/src/vcash/src/coin/test/build-system, /usr/share/boost-build).

Please consult the documentation at 'http://www.boost.org'.

Raynman · 2017-07-06 09:15:47

Maybe https://aur.archlinux.org/packages/boost-build/ ?

Trilby · 2017-07-06 10:24:05

Sorry I don't actually have experience with boost's build system, but I'd be pretty sure some around here do. It looks like Raynman is right, that package has the boostrap.jam. I just tried it but it wasn't obvious how to build with bjam/b2. I had a few b2 commands complete successfully and report build targets, but nothing actually built.

I would *think* getting the build system this software was intended to use would be easier than trying to symlink or hack something else together - but that build system is new to me.

sum01 · 2017-07-13 06:41:04

So yes, boost-build did get me past the previous issues, but of course I ran into all the broken Jamfile's. I gave up and moved on to creating a cmake fork. https://github.com/sum01/vcash/tree/add … nd-cleanup

It builds/works on Ubuntu, but I'm having issues getting it to work with OpenSSL on Arch.
I tried to get around this by making a Find module to get OpenSSL-1.0 libs and paths https://github.com/sum01/vcash/blob/add … ts.txt#L50, which it does get the paths, but it seems that https://github.com/sum01/vcash/blob/add … er.hpp#L29 is ignoring my paths provided by the custom find module.

Anyone know how to actually get it to use the OpenSSL-1.0 paths/libs?

EDIT: Maybe this is more a question for the programming thread. I'll move over there.

Last edited by sum01 (2017-07-13 16:36:22)

Arch Linux

#1 2017-07-03 22:19:31

Symlink to deps - is it stupid?

#2 2017-07-03 23:50:20

Re: Symlink to deps - is it stupid?

#3 2017-07-04 00:09:00

Re: Symlink to deps - is it stupid?

#4 2017-07-04 00:37:01

Re: Symlink to deps - is it stupid?

#5 2017-07-04 01:15:12

Re: Symlink to deps - is it stupid?

#6 2017-07-06 01:42:12

Re: Symlink to deps - is it stupid?

#7 2017-07-06 09:15:47

Re: Symlink to deps - is it stupid?

#8 2017-07-06 10:24:05

Re: Symlink to deps - is it stupid?

#9 2017-07-13 06:41:04

Re: Symlink to deps - is it stupid?

Board footer