cmake.port.mk and DEBUG
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.
So here's the simple diff that does less and makes DEBUG=-g actually
usable.
ok?
Index: cmake.port.mk
===
RCS file: /d/cvs/ports/devel/cmake/cmake.port.mk,v
retrieving revision 1.62
diff -u -p -p -u -r1.62 cmake.port.mk
--- cmake.port.mk 28 Nov 2017 10:26:00 - 1.62
+++ cmake.port.mk 8 Jan 2018 09:37:03 -
@@ -76,13 +76,8 @@ MODCMAKE_configure= cd ${WRKBUILD} && ${
-G ${_MODCMAKE_GEN} ${CONFIGURE_ARGS} ${WRKSRC}
.if !defined(CONFIGURE_ARGS) || ! ${CONFIGURE_ARGS:M*CMAKE_BUILD_TYPE*}
-. if defined(DEBUG)
-CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE:String=Debug
-MODCMAKE_BUILD_SUFFIX =-debug.cmake
-. else
CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE:String=Release
MODCMAKE_BUILD_SUFFIX =-release.cmake
-. endif
.endif
SUBST_VARS += MODCMAKE_BUILD_SUFFIX
* why isn't MODCMAKE_BUILD_SUFFIX properly substituted in all PLISTs?
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: cmake.port.mk and DEBUG
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
Re: cmake.port.mk and DEBUG
On Fri, Jan 19, 2018 at 02:18:53PM +, 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.
>
> So here's the simple diff that does less and makes DEBUG=-g actually
> usable.
>
> ok?
>
>
>
> Index: cmake.port.mk
> ===
> RCS file: /d/cvs/ports/devel/cmake/cmake.port.mk,v
> retrieving revision 1.62
> diff -u -p -p -u -r1.62 cmake.port.mk
> --- cmake.port.mk 28 Nov 2017 10:26:00 - 1.62
> +++ cmake.port.mk 8 Jan 2018 09:37:03 -
> @@ -76,13 +76,8 @@ MODCMAKE_configure=cd ${WRKBUILD} && ${
> -G ${_MODCMAKE_GEN} ${CONFIGURE_ARGS} ${WRKSRC}
>
> .if !defined(CONFIGURE_ARGS) || ! ${CONFIGURE_ARGS:M*CMAKE_BUILD_TYPE*}
> -. if defined(DEBUG)
> -CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE:String=Debug
> -MODCMAKE_BUILD_SUFFIX = -debug.cmake
> -. else
> CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE:String=Release
> MODCMAKE_BUILD_SUFFIX = -release.cmake
> -. endif
> .endif
> SUBST_VARS +=MODCMAKE_BUILD_SUFFIX
>
>
> * why isn't MODCMAKE_BUILD_SUFFIX properly substituted in all PLISTs?
I think that's the main issue isn't it?
We can probably fix the framework to do so.
--
Antoine
Re: cmake.port.mk and DEBUG
On Sat, Jan 20 2018, Landry Breuil 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
Re: cmake.port.mk and DEBUG
On Sat, Jan 20 2018, Antoine Jacoutot wrote: > On Fri, Jan 19, 2018 at 02:18:53PM +, Jeremie Courreges-Anglas wrote: [...] >> * why isn't MODCMAKE_BUILD_SUFFIX properly substituted in all PLISTs? > > I think that's the main issue isn't it? > We can probably fix the framework to do so. Nope. This blurb about MODCMAKE_BUILD_SUFFIX not being substituted is just me being stupid. But given that I'm perfectly fine with being stupid, I'm not happy with a module overloading DEBUG, inserting random CFLAGS at upstream's will and triggering PLIST_DB changes. And I'm not the only one that has been bitten by this, I recall at least three other developers and one user losing time on this. So I'm advocating for less magic. :) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: cmake.port.mk and DEBUG
On 2018/01/20 13:08, Jeremie Courreges-Anglas wrote: > On Sat, Jan 20 2018, Landry Breuil 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
Re: cmake.port.mk and DEBUG
On Sat, Jan 20 2018, Stuart Henderson wrote:
[...]
> 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..)
Looks like several people agree with this direction, so here's a diff
that adds MODCMAKE_DEBUG.
Comments/oks?
Index: share/man/man5/port-modules.5
===
RCS file: /d/cvs/src/share/man/man5/port-modules.5,v
retrieving revision 1.225
diff -u -p -r1.225 port-modules.5
--- share/man/man5/port-modules.5 2 Dec 2017 09:31:52 - 1.225
+++ share/man/man5/port-modules.5 21 Jan 2018 16:58:03 -
@@ -569,6 +569,13 @@ If set to `Yes', CMake will print detail
stages about exact command being run, etc.
Should not be used in ports Makefiles.
Default value is `Yes'.
+.It MODCMAKE_DEBUG
+If set to `Yes', CMake will produce a debug build instead of a release
+build.
+The exact effects on the build process depend on settings specified in
+the CMake config files.
+Also files in the resulting package might named differently.
+Default value is `No'.
.El
Also,
.Sq nojunk
Index: devel/cmake/cmake.port.mk
===
RCS file: /d/cvs/ports/devel/cmake/cmake.port.mk,v
retrieving revision 1.62
diff -u -p -r1.62 cmake.port.mk
--- devel/cmake/cmake.port.mk 28 Nov 2017 10:26:00 - 1.62
+++ devel/cmake/cmake.port.mk 21 Jan 2018 16:51:31 -
@@ -65,6 +65,8 @@ CONFIGURE_ENV += MODJAVA_VER=${MODJAVA_V
MODTCL_LIB=${MODTCL_LIB} \
MODTK_LIB=${MODTK_LIB}
+MODCMAKE_DEBUG ?= No
+
.if empty(CONFIGURE_STYLE)
CONFIGURE_STYLE= cmake
.endif
@@ -76,7 +78,7 @@ MODCMAKE_configure= cd ${WRKBUILD} && ${
-G ${_MODCMAKE_GEN} ${CONFIGURE_ARGS} ${WRKSRC}
.if !defined(CONFIGURE_ARGS) || ! ${CONFIGURE_ARGS:M*CMAKE_BUILD_TYPE*}
-. if defined(DEBUG)
+. if ${MODCMAKE_DEBUG:L} == "yes"
CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE:String=Debug
MODCMAKE_BUILD_SUFFIX =-debug.cmake
. else
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: cmake.port.mk and DEBUG
On Sun, Jan 21, 2018 at 06:00:24PM +0100, Jeremie Courreges-Anglas wrote: > On Sat, Jan 20 2018, Stuart Henderson wrote: > > [...] > > > 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..) > > Looks like several people agree with this direction, so here's a diff > that adds MODCMAKE_DEBUG. > > Comments/oks? > > > Index: share/man/man5/port-modules.5 > === > RCS file: /d/cvs/src/share/man/man5/port-modules.5,v > retrieving revision 1.225 > diff -u -p -r1.225 port-modules.5 > --- share/man/man5/port-modules.5 2 Dec 2017 09:31:52 - 1.225 > +++ share/man/man5/port-modules.5 21 Jan 2018 16:58:03 - > @@ -569,6 +569,13 @@ If set to `Yes', CMake will print detail > stages about exact command being run, etc. > Should not be used in ports Makefiles. > Default value is `Yes'. > +.It MODCMAKE_DEBUG > +If set to `Yes', CMake will produce a debug build instead of a release > +build. > +The exact effects on the build process depend on settings specified in > +the CMake config files. > +Also files in the resulting package might named differently. missing verb ? And i think, since ppl wont understand what it means
Re: cmake.port.mk and DEBUG
On Sun, Jan 21 2018, Landry Breuil wrote:
> On Sun, Jan 21, 2018 at 06:00:24PM +0100, Jeremie Courreges-Anglas wrote:
>> On Sat, Jan 20 2018, Stuart Henderson wrote:
>>
>> [...]
>>
>> > 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..)
>>
>> Looks like several people agree with this direction, so here's a diff
>> that adds MODCMAKE_DEBUG.
>>
>> Comments/oks?
[...]
> missing verb ? And i think, since ppl wont understand what it means
Yep, sorry. Do you suggest deleting the whole sentence?
Index: share/man/man5/port-modules.5
===
RCS file: /d/cvs/src/share/man/man5/port-modules.5,v
retrieving revision 1.225
diff -u -p -r1.225 port-modules.5
--- share/man/man5/port-modules.5 2 Dec 2017 09:31:52 - 1.225
+++ share/man/man5/port-modules.5 21 Jan 2018 17:33:29 -
@@ -569,6 +569,12 @@ If set to `Yes', CMake will print detail
stages about exact command being run, etc.
Should not be used in ports Makefiles.
Default value is `Yes'.
+.It MODCMAKE_DEBUG
+If set to `Yes', CMake will produce a debug build instead of a release
+build.
+The exact effects on the build process depend on settings specified in
+the CMake config files.
+Default value is `No'.
.El
Also,
.Sq nojunk
Index: devel/cmake/cmake.port.mk
===
RCS file: /d/cvs/ports/devel/cmake/cmake.port.mk,v
retrieving revision 1.62
diff -u -p -r1.62 cmake.port.mk
--- devel/cmake/cmake.port.mk 28 Nov 2017 10:26:00 - 1.62
+++ devel/cmake/cmake.port.mk 21 Jan 2018 16:51:31 -
@@ -65,6 +65,8 @@ CONFIGURE_ENV += MODJAVA_VER=${MODJAVA_V
MODTCL_LIB=${MODTCL_LIB} \
MODTK_LIB=${MODTK_LIB}
+MODCMAKE_DEBUG ?= No
+
.if empty(CONFIGURE_STYLE)
CONFIGURE_STYLE= cmake
.endif
@@ -76,7 +78,7 @@ MODCMAKE_configure= cd ${WRKBUILD} && ${
-G ${_MODCMAKE_GEN} ${CONFIGURE_ARGS} ${WRKSRC}
.if !defined(CONFIGURE_ARGS) || ! ${CONFIGURE_ARGS:M*CMAKE_BUILD_TYPE*}
-. if defined(DEBUG)
+. if ${MODCMAKE_DEBUG:L} == "yes"
CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE:String=Debug
MODCMAKE_BUILD_SUFFIX =-debug.cmake
. else
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: cmake.port.mk and DEBUG
On Sun, Jan 21 2018, Jeremie Courreges-Anglas wrote:
> On Sun, Jan 21 2018, Landry Breuil wrote:
>> On Sun, Jan 21, 2018 at 06:00:24PM +0100, Jeremie Courreges-Anglas wrote:
>>> On Sat, Jan 20 2018, Stuart Henderson wrote:
>>>
>>> [...]
>>>
>>> > 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..)
>>>
>>> Looks like several people agree with this direction, so here's a diff
>>> that adds MODCMAKE_DEBUG.
>>>
>>> Comments/oks?
>
> [...]
>
>> missing verb ? And i think, since ppl wont understand what it means
>
> Yep, sorry. Do you suggest deleting the whole sentence?
ping.
> Index: share/man/man5/port-modules.5
> ===
> RCS file: /d/cvs/src/share/man/man5/port-modules.5,v
> retrieving revision 1.225
> diff -u -p -r1.225 port-modules.5
> --- share/man/man5/port-modules.5 2 Dec 2017 09:31:52 - 1.225
> +++ share/man/man5/port-modules.5 21 Jan 2018 17:33:29 -
> @@ -569,6 +569,12 @@ If set to `Yes', CMake will print detail
> stages about exact command being run, etc.
> Should not be used in ports Makefiles.
> Default value is `Yes'.
> +.It MODCMAKE_DEBUG
> +If set to `Yes', CMake will produce a debug build instead of a release
> +build.
> +The exact effects on the build process depend on settings specified in
> +the CMake config files.
> +Default value is `No'.
> .El
> Also,
> .Sq nojunk
> Index: devel/cmake/cmake.port.mk
> ===
> RCS file: /d/cvs/ports/devel/cmake/cmake.port.mk,v
> retrieving revision 1.62
> diff -u -p -r1.62 cmake.port.mk
> --- devel/cmake/cmake.port.mk 28 Nov 2017 10:26:00 - 1.62
> +++ devel/cmake/cmake.port.mk 21 Jan 2018 16:51:31 -
> @@ -65,6 +65,8 @@ CONFIGURE_ENV +=MODJAVA_VER=${MODJAVA_V
> MODTCL_LIB=${MODTCL_LIB} \
> MODTK_LIB=${MODTK_LIB}
>
> +MODCMAKE_DEBUG ?=No
> +
> .if empty(CONFIGURE_STYLE)
> CONFIGURE_STYLE= cmake
> .endif
> @@ -76,7 +78,7 @@ MODCMAKE_configure= cd ${WRKBUILD} && ${
> -G ${_MODCMAKE_GEN} ${CONFIGURE_ARGS} ${WRKSRC}
>
> .if !defined(CONFIGURE_ARGS) || ! ${CONFIGURE_ARGS:M*CMAKE_BUILD_TYPE*}
> -. if defined(DEBUG)
> +. if ${MODCMAKE_DEBUG:L} == "yes"
> CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE:String=Debug
> MODCMAKE_BUILD_SUFFIX = -debug.cmake
> . else
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: cmake.port.mk and DEBUG
On Fri, Jan 26, 2018 at 12:22:56PM +0100, Jeremie Courreges-Anglas wrote: > On Sun, Jan 21 2018, Jeremie Courreges-Anglas wrote: > > On Sun, Jan 21 2018, Landry Breuil wrote: > >> On Sun, Jan 21, 2018 at 06:00:24PM +0100, Jeremie Courreges-Anglas wrote: > >>> On Sat, Jan 20 2018, Stuart Henderson wrote: > >>> > >>> [...] > >>> > >>> > 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..) > >>> > >>> Looks like several people agree with this direction, so here's a diff > >>> that adds MODCMAKE_DEBUG. > >>> > >>> Comments/oks? > > > > [...] > > > >> missing verb ? And i think, since ppl wont understand what it means > > > > Yep, sorry. Do you suggest deleting the whole sentence? > > ping. I feel uncomfortable with it, but okay :)
