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' ? > 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 ? :) 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 ? 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... Landry
