NetBSD Problem Report #48784

From www@NetBSD.org  Mon May  5 14:53:11 2014
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id D102CA580B
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  5 May 2014 14:53:11 +0000 (UTC)
Message-Id: <20140505145310.3D8FEA5830@mollari.NetBSD.org>
Date: Mon,  5 May 2014 14:53:10 +0000 (UTC)
From: frank@phoenix.owl.de
Reply-To: frank@phoenix.owl.de
To: gnats-bugs@NetBSD.org
Subject: cmake-2.8.11.2nb1: CmakeCache defaults are missing
X-Send-Pr-Version: www-1.0

>Number:         48784
>Category:       pkg
>Synopsis:       cmake-2.8.11.2nb1: CmakeCache defaults are missing
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    adam
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 05 14:55:00 +0000 2014
>Closed-Date:    Thu Jul 20 13:18:13 +0000 2023
>Last-Modified:  Thu Jul 20 13:18:13 +0000 2023
>Originator:     Frank Wille
>Release:        2014Q1
>Organization:
NetBSD
>Environment:
Probably all NetBSD machines. For example:

NetBSD sun.hasenbraten.de 6.1.4 NetBSD 6.1.4 (FIREV240) #0: Sun May  4 14:40:37 CEST 2014  frank@tethys:/home/frank/netbsd/REL6.1.4/src/objsparc64/sys/arch/sparc64/compile/FIREV240 sparc64

>Description:
After running "cmake ." the CMakeCache.txt doesn't provide any default
options for the compiler or linker. With cmake-2.8.11.2nb1 the entries
in CMakeCache.txt look like this:

---8<---
//C compiler.
CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc

//Flags used by the compiler during all build types.
CMAKE_C_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_C_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release minsize builds.
CMAKE_C_FLAGS_MINSIZEREL:STRING= -DNDEBUG

//Flags used by the compiler during release builds (/MD /Ob1 /Oi
// /Ot /Oy /Gs will produce slightly less optimized but smaller
// files).
CMAKE_C_FLAGS_RELEASE:STRING= -DNDEBUG

//Flags used by the compiler during Release with Debug Info builds.
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING= -g -DNDEBUG
---8<---

This has for example the effect that applications built with cmake are
compiled without optimization and are unnecessarily slow.


It looked much better in the past, with cmake-2.6.2 from pkgsrc-2009Q1:

---8<---
//C compiler.
CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc

//Flags used by the compiler during all build types.
CMAKE_C_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_C_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release minsize builds.
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds (/MD /Ob1 /Oi
// /Ot /Oy /Gs will produce slightly less optimized but smaller
// files).
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during Release with Debug Info builds.
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g
---8<---

>How-To-Repeat:
Generate a CMakeCache.txt with any source distribution requiring cmake.
For example Hatari 1.7.0:
http://download.tuxfamily.org/hatari/1.7.0/hatari-1.7.0.tar.bz2

Run "./configure" or "cmake .". Look into CMakeCache.txt.

>Fix:
Unknown.

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: pkg-manager->wiz
Responsible-Changed-By: ryoon@NetBSD.org
Responsible-Changed-When: Tue, 06 May 2014 00:03:34 +0000
Responsible-Changed-Why:
over to maintainer


State-Changed-From-To: open->feedback
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Tue, 06 May 2014 08:44:38 +0000
State-Changed-Why:
Do I understand correctly that your point is that the -O flags
are not there any longer?
If so, I don't see that as an issue, because they should be provided
by the user and not by the build system.


From: Frank Wille <frank@phoenix.owl.de>
To: gnats-bugs@NetBSD.org
Cc: wiz@NetBSD.org, pkgsrc-bugs@netbsd.org, gnats-admin@netbsd.org
Subject: Re: pkg/48784 (cmake-2.8.11.2nb1: CmakeCache defaults are missing)
Date: Tue, 6 May 2014 11:50:46 +0200

 On Tue,  6 May 2014 08:44:38 +0000 (UTC)
 wiz@NetBSD.org wrote:

 > Synopsis: cmake-2.8.11.2nb1: CmakeCache defaults are missing
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: wiz@NetBSD.org
 > State-Changed-When: Tue, 06 May 2014 08:44:38 +0000
 > State-Changed-Why:
 > Do I understand correctly that your point is that the -O flags
 > are not there any longer?

 Correct.


 > If so, I don't see that as an issue, because they should be provided
 > by the user and not by the build system.

 I must admit that I have not much experience with cmake, but it worked
 before, and as there are configuration variables for each kind of build
 (CMAKE_C_FLAGS, CMAKE_C_FLAGS_DEBUG, CMAKE_C_FLAGS_RELEASE) I think they
 should be preset with sane defaults. And no optimization at all is insane,
 when doing a release-build. :)


 -- 
 Frank Wille

Responsible-Changed-From-To: wiz->adam
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Tue, 06 May 2014 21:50:55 +0000
Responsible-Changed-Why:
adam added this in 2010, and I agree with him... but let him handle this.
(look in the Makefile for the SUBST statement that does this)


State-Changed-From-To: feedback->analyzed
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Tue, 06 May 2014 21:50:55 +0000
State-Changed-Why:
see above


From: Adrian Tulloch <adrian@reyes-tulloch.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/48784
Date: Mon, 1 Feb 2016 16:34:30 +1100

 --047d7bd758d23840f3052aaebd40
 Content-Type: text/plain; charset=UTF-8

 I know this is an old issue, but I am hoping that this could be
 reconsidered.

 I have also been tripped up by this, and, like Frank, think that removing
 optimization flags for release builds goes against the expectations of a
 CMake user.

 For what it's worth, at one stage the macports project also removed the
 CMake optimisation flags, then re-instated them because:

 The consequence of having a few cmake macports compiling with '-O3' is much
 > less serious than the consequence of every user-installed code marked
 > 'Release' unintentionally being compiled with -O0
 >

 For details see https://trac.macports.org/ticket/40648

 I know it was a long time ago, but does anyone remember why the cmake
 default optimization flags were removed? Was it because -O3 broke some
 packages that configure themselves using cmake?

 Adrian Tulloch

 --047d7bd758d23840f3052aaebd40
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable

 <div dir=3D"ltr">I know this is an old issue, but I am hoping that this cou=
 ld be reconsidered.<div><br></div><div>I have also been tripped up by this,=
  and, like Frank, think that removing optimization flags for release builds=
  goes against the expectations of a CMake user.</div><div><br></div><div>Fo=
 r what it&#39;s worth, at one stage the macports project also removed the C=
 Make optimisation flags, then re-instated them because:</div><div><br></div=
 ><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
 -left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
 padding-left:1ex"><span style=3D"color:rgb(0,0,0);font-family:&#39;Lucida G=
 rande&#39;,Verdana,Arial,Helvetica,sans-serif;font-size:13px">The consequen=
 ce of having a few cmake macports compiling with &#39;-O3&#39; is much less=
  serious than the consequence of every user-installed code marked &#39;Rele=
 ase&#39; unintentionally being compiled with -O0</span><br></blockquote><di=
 v><br></div><div>For details see <a href=3D"https://trac.macports.org/ticke=
 t/40648">https://trac.macports.org/ticket/40648</a></div><div><br></div><di=
 v>I know it was a long time ago, but does anyone remember why the cmake def=
 ault optimization flags were removed? Was it because -O3 broke some package=
 s that configure themselves using cmake?</div><div><br></div><div>Adrian Tu=
 lloch</div></div>

 --047d7bd758d23840f3052aaebd40--

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/48784
Date: Mon, 1 Feb 2016 08:29:14 +0000

 On Mon, Feb 01, 2016 at 05:35:01AM +0000, Adrian Tulloch wrote:
  >  I know this is an old issue, but I am hoping that this could be
  >  reconsidered.
  >  
  >  I have also been tripped up by this, and, like Frank, think that removing
  >  optimization flags for release builds goes against the expectations of a
  >  CMake user.

 gcc's output without at least -O is so awful that it's not useful to
 build that way except when specifically required for debugging.

 ergo, if cmake-built packages aren't getting -O or preferably -O2 from
 somewhere else, it should go back into the cmake defaults.

 IMO.

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: analyzed->closed
State-Changed-By: adam@NetBSD.org
State-Changed-When: Thu, 20 Jul 2023 13:18:13 +0000
State-Changed-Why:
I don't think this is relevant anymore - current CMake adds CMAKE_CXX_FLAGS:STRING=-O2 and CMAKE_C_FLAGS:STRING=-O2 for all build types.


>Unformatted:

Home	PR Database Search