tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: (lots of) USE_CMAKE considered harmful
Hauke Fath <hf%spg.tu-darmstadt.de@localhost> writes:
> Breaks www/hiawatha:
>
> hiawatha.conf.in file is not being processed
>
> and
>
> => Checking for missing run-time search paths in hiawatha-11.6
> ERROR: sbin/hiawatha: missing library: libmbedx509.so.7
> ERROR: sbin/hiawatha: missing library: libmbedcrypto.so.16
> ERROR: sbin/hiawatha: missing library: libmbedtls.so.21
> ERROR: sbin/wigwam: missing library: libmbedx509.so.7
> ERROR: sbin/wigwam: missing library: libmbedcrypto.so.16
> ERROR: sbin/wigwam: missing library: libmbedtls.so.21
>
> when the libraries have been built and installed - looks like an rpath
> issue.
My opinion has been that cmake rpath handling is messy and I'm standing
by it!
> What are the (relevant) differences between the USE_CMAKE setup and
> devel/cmake/build.mk?
I really don't know; you can compare mk/configure/cmake.mk and
devel/cmake/build.mk, and perhaps build both ways with
PKG_DEBUG_LEVEL=1. It is reasonably likely that there is some minor
difference in cmake rpath args, and perhaps one that interacts badly
with this particular package.
I would also look at libmbedtls and see if it is setting CMAKE_ARGS. We
are in a messy situation now where packages set CMAKE_ARGS or
CMAKE_CONFIGURE_ARGS depending on which build flavor they are
accomodating. Hence my "let's get rid of the USE_CMAKE method to reduce
confusion".
Home |
Main Index |
Thread Index |
Old Index