On 2018/01/20 13:08, Jeremie Courreges-Anglas wrote: > On Sat, Jan 20 2018, Landry Breuil <[email protected]> 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.
How about making the cmake debug-build stuff dependent on a flavour (like "CMAKE_DEBUG") rather than making DEBUG do double-duty as a compiler flag option *and* a cmake knob? (We already removed some other cases where DEBUG turned on port-specific debug options..)
