On Thu Oct 08, 2020 at 10:18:44AM +0100, Stuart Henderson wrote: > moved to ports@ > > In gmane.os.openbsd.misc, you wrote: > > On Tue, 6 Oct 2020 13:29:56 -0000 (UTC) > > Stuart Henderson <[email protected]> wrote: > > > >> On 2020-10-05, Julian Smith <[email protected]> wrote: > >> > It looks like OpenBSD's cmake port patches cmake to remove the use > >> > of -O2 in Release and RelWithDebInfo builds - > >> > /usr/ports/devel/cmake/patches/patch-Modules_Compiler_GNU_cmake has: > >> > > >> > - string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os > >> > -DNDEBUG") > >> > - string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -O3 -DNDEBUG") > >> > - string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -O2 -g > >> > -DNDEBUG") > >> > + string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -DNDEBUG") > >> > + string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -DNDEBUG") > >> > + string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -g > >> > -DNDEBUG") > >> > > >> > Does anyone know why things are patched in this way? > >> > > >> > > >> > [I think one can force optimisation with (for example): > >> > > >> > cmake -DCMAKE_CXX_FLAGS_RELWITHDEBINFO="-O2 -g -DNDEBUG" ... > >> > ] > >> > > >> > > >> > Thanks, > >> > > >> > - Jules > >> > > >> > >> It's setup to work with builds done from ports, which should not > >> override whatever optimization level is set by either the user or the > >> build infrastructure. > >> > >> The downside is that you need to add this yourself for builds from > >> outside ports. > > > > Thanks for the explanation. > > > > Would it be worth documenting this in the cmake(1) manpage? If so, i'll > > submit a patch. > > > > It's quite confusing to have cmake not optimise by default for Release > > or RelWithDeb builds - i built OpenSceneGraph-3.6 while working on > > Flightgear and it took a rather long time to figure out why i was > > getting such a reduced frame rate. > > I seriously doubt anyone will see it in the manpage. Might be better if > things are rearranged so these are only stripped for ports builds, maybe by > having ports infrastructure set a flag (either as a cmake variable or > passed via the environment) and detecting that. > > Generally you are better off working within the ports infrastructure rather > than outside it if you're updating things already in ports, or working on > something destined to be a port, But I do think it's still best if cmake > works as expected for non-ports builds too. >
Thanks Stuart for forwarding to ports@. To be honest devel/cmake is very strongly modified to be used in our ports/bulk universe. I would like to patch it all out and make it optional by cmake.port.mk. For example like this One for all ... CONFIGURE_ARGS += -DOPENBSD_BUILD=ON or an env var. or a single option for the respective openbsd bulk hack. It is on my list unless someone wants to support me. Rafael
