On Sat, Jan 20 2018, Landry Breuil <lan...@openbsd.org> wrote: > On Fri, Jan 19, 2018 at 03:18:53PM +0100, Jeremie Courreges-Anglas wrote: >> >> Once again I've been bitten by the special handling of DEBUG done in >> cmake.port.mk. >> >> First, cmake might use different CFLAGS in debug and release mode (this >> is usually specified by upstream in CMakeLists.txt). Those CFLAGS might >> be undesirable or even unusable on OpenBSD (iirc some stuff might try to >> link against valgrind or ubsan / whatever). Those might be useful but >> IMO you shouldn't get to use them when all you want is to rebuild a port >> with DEBUG=-g, ie debug symbols. >> >> Also the release/debug difference means that some ports just won't >> package because of file names changes: >> >> --8<-- >> ===> Building package for libical-3.0.1 >> Create /usr/ports/packages/amd64/all/libical-3.0.1.tgz >> Creating package libical-3.0.1 >> Error: change in plist >> | If the old and new builds were done correctly >> | (fully up-to-date ports tree including relevant MODULES) >> | then someone probably forgot to bump a REVISION. >> | (see bsd.port.mk(5), PACKAGE_REPOSITORY) >> --- /usr/ports/plist/amd64/libical-3.0.1 >> +++ /usr/ports/plist/amd64/libical-3.0.1-new >> @@ -74,7 +74,7 @@ >> lib/cmake/LibIcal/ >> lib/cmake/LibIcal/LibIcalConfig.cmake >> lib/cmake/LibIcal/LibIcalConfigVersion.cmake >> -lib/cmake/LibIcal/LibIcalTargets-release.cmake >> +lib/cmake/LibIcal/LibIcalTargets-debug.cmake >> lib/cmake/LibIcal/LibIcalTargets.cmake >> lib/girepository-1.0/ >> lib/girepository-1.0/ICalGLib-3.0.typelib >> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1943 >> '/usr/ports/packages/amd64/all/libical-3.0.1.tgz') >> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2440 >> '_internal-package') >> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2419 'package') >> *** Error 1 in /usr/ports/textproc/libical >> (/usr/ports/infrastructure/mk/bsd.port.mk:3421 'repackage') >> -->8-- >> >> $ pkglocate release.cmake | wc -l >> 150 >> >> I think it's fair to say that the ports tree is not ready to use >> cmake with DEBUG=-g. This could be fixed in theory, but someone has to >> do the work*, and is does not invalidate my first point. > > What do you mean by 'not ready' ?
As a dumb porter, I'd like to be able to use DEBUG=-g and expect it to add debug symbols to the resulting package. Not to fail at compile time because of alien CFLAGS suddenly appearing, not to fail at make package time because of PLIST changes. DEBUG=-g is a super useful tool that allowed me to fix quite a bunch of problems in the past and present days. (Of course for this DEBUG=-g should be respected by each ports' build system, but that's a separate issue.) >> So here's the simple diff that does less and makes DEBUG=-g actually >> usable. > > As the one with came up with what you're proposing to revert, i had to > sit and look again. I thought i had done this recently, but it turns out > it was already 3+ years ago in r1.34. > > My usecase was at the time, i want to be able to just set DEBUG, and > have cmake build with upstream-provided debug configuration (setting > various flags, not only CFLAGS) because that's much more different and > useful (*in my opinion*) that just setting -g: sometimes it enables > verbose logging on the output, sometimes different codepaths are used > for debugging corner cases - this is *convenient*, but i agree it > totally depends on the case and what upstream made special in the debug > build type. > > For example, i don't want to use gdb on qgis, unless in an extremely > desperate case. > > When you set CMAKE_BUILD_TYPE, cmake installs the -debug.cmake file > instead of the -release.cmake file, so MODCMAKE_BUILD_SUFFIX was added > so that ports packaged. Minus the eventual PLIST_DB warning, but you > know make clean=plist right ? :) Nope. PLIST_DB is super useful and having to ditch it as a work-around is less than optimal in my book. IMHO, the ports tree should be ready to build and package with DEBUG=-g set. (No, I'm not suggesting that people should use this in their /etc/mk.conf.) > If you don't like the fact that it's 'automagic' with DEBUG, change the > variable to have it in a distinct way (dunno, MODCMAKE_DEBUG?) that sets > CMAKE_BUILD_TYPE and MODCMAKE_BUILD_SUFFIX (and DEBUG while here?) like > it's done now with DEBUG ? I would support any solution that doesn't overload the semantics of DEBUG. > With DEBUG set it was convenient because it also (iirc) disabled > stripping, but i dont know if it has any effect with cmake-builds. > >> * why isn't MODCMAKE_BUILD_SUFFIX properly substituted in all PLISTs? > > Well, some do it right, some don't and they need to be fixed ? I've just > fixed the 3 occurences that were wrong, over 150... no so bad, right ? > If we want to keep it that way, could be one more check to add to > portcheck for the ones that use it... I'll trust you about the 3 over 150 occurences, given that I was completely off the map when using pkglocate for this. But my points stand. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
