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