Nice overview Landry, thanks! I took a look at it too. I think the problem for us is how cmake ninja/make builds.
We can read for ninja and Unix makefiles install step: "Runs the install step in the subdirectory followed by a CMAKE_STRIP command, if any. The CMAKE_STRIP variable will contain the platform’s strip utility, which removes symbols information from generated binaries." https://cmake.org/cmake/help/v3.17/generator/Unix%20Makefiles.html?highlight=cmake_strip https://cmake.org/cmake/help/v3.17/generator/Ninja.html?highlight=cmake_strip For me, that means, if we run "make fake" we trigger install witch trigger the strip job. I already started[1] to avoid using ninja/make for all generated targets (build, install, test and so one) because cmake(1) can do it for use: https://cmake.org/cmake/help/v3.17/manual/cmake.1.html It looks to me like it doesn't strip automatically because there's a knob for it: --strip https://cmake.org/cmake/help/v3.17/manual/cmake.1.html#install-a-project [1]: https://github.com/sizeofvoid/wip-ports/commit/b8da77ca08387c70e0a3efaa1ba5b3c7ad44236 More comments below: On Sun Apr 19, 2020 at 09:07:10AM +0200, Landry Breuil wrote: > Hi, > > i've had a look at why cmake insists on striping libs/binaries (even if > it seems upstream states it isnt the case by default.. no 100% sure > about this statment), rendering our DEBUG_PACKAGES framework useless for > (some?) cmake ports. CMAKE_BUILD_TYPE=RelWithDebInfo doesnt really work > as it produces different binaries, and it would be great to have a > 'generic' solution that would work for all cmake ports. > > after looking at the cmake code there are two things/knobs: > CMAKE_INSTALL_DO_STRIP seem to control which sub makefile is called, but > upstream wants to hide it from the API: > https://gitlab.kitware.com/cmake/cmake/commit/d5b722bbbd684477e8b8a979ba62a2f1b45a720c > > CMAKE_STRIP is the path to the strip utility, looked for in > https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/CMakeFindBinUtils.cmake#L113 > > the 'interesting' generator bits are here: > https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmGlobalGenerator.cxx#L2663 > https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmInstallTargetGenerator.cxx#L785 > > those could be patched out,i'd say 'remove the line force-adding > -DCMAKE_INSTALL_DO_STRIP=1' but then that would affect all cmake-using > ports, where we'd have to change more bits to actually do the striping > somewhere else ? but first, id prefer something less invasive, using > only user-knobs via DEBUG_CONFIGURE_ARGS. > > tried: > * -DCMAKE_INSTALL_DO_STRIP=0 -> no dice, not meant as a user-visible knob: > Manually-specified variables were not used by the project: > CMAKE_INSTALL_DO_STRIP There is no documentation for CMAKE_INSTALL_DO_STRIP. > > * -UCMAKE_STRIP to avoid cmake looking for CMAKE_STRIP -> still finds it. I see no documentation to stop it. > > * -DCMAKE_STRIP=/usr/bin/true seems to be taken into account: > /usr/obj/ports/freerdp-2.0.0rc1/build-amd64/CMakeCache.txt:CMAKE_STRIP:FILEPATH=/usr/bin/true > > and the resulting package seems to provide debug syms: > [08:53] nikki:~/ $egdb /usr/local/bin/xfreerdp > Reading symbols from /usr/local/bin/xfreerdp...Reading symbols from > /usr/local/bin/.debug/xfreerdp.dbg...done. > > so it seems this: > Index: Makefile > =================================================================== > RCS file: /cvs/ports/x11/freerdp/Makefile,v > retrieving revision 1.39 > diff -u -r1.39 Makefile > --- Makefile 4 Nov 2019 10:30:20 -0000 1.39 > +++ Makefile 19 Apr 2020 06:55:41 -0000 > @@ -8,6 +8,8 @@ > PKGNAME = freerdp-2.0.0rc1 > REVISION = 4 > CATEGORIES = x11 net > +DEBUG_PACKAGES= ${BUILD_PACKAGES} > +DEBUG_CONFIGURE_ARGS+= -DCMAKE_STRIP=/usr/bin/true > > actually works for freerdp (but apparently, after retesting twice and > being puzzled, without overriding CMAKE_STRIP i have a working > debug-freerdp package). Can others check with various cmake ports that > were reluctant to work with only DEBUG_PACKAGES set ? Should > DEBUG_CONFIGURE_ARGS be set by default in cmake.port.mk - leaving the > DEBUG_PACKAGES knob to be the only line added to ports Makefiles as is > the case with autohell-based ports ? I think C-DCMAKE_STRIP=/usr/bin/true is promising for our current cmake-ports-env. > > Landry
