Bug 203793 - Fix devel/cmake-modules so it prefers "c++" over "CC" for compiling C++ programs
Summary: Fix devel/cmake-modules so it prefers "c++" over "CC" for compiling C++ programs
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Adriaan de Groot
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-15 17:52 UTC by Dimitry Andric
Modified: 2017-09-27 09:29 UTC (History)
4 users (show)

See Also:
rakuco: maintainer-feedback+


Attachments
Fix devel/cmake-modules to it prefers "c++" over "CC" for compiling C++ programs (1.88 KB, patch)
2015-10-15 17:52 UTC, Dimitry Andric
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitry Andric freebsd_committer 2015-10-15 17:52:44 UTC
Created attachment 162078 [details]
Fix devel/cmake-modules to it prefers "c++" over "CC" for compiling C++ programs

Related to bug 200475, which was about an exp-run with the "CC" alias for "c++" removed from the base system, I noticed that even the latest CMake port still prefers "CC" over "c++" whenever it can find it.

This is all due to a pretty old upstream commit in CMake:
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e58e5bb68cb058370b5015f576ee5507e56facc

The commit message has: 'By default use "cc" for C, "CC" for C++, and "f95" for Fortran.'

I would like to change the default for C++, and the order in which the compilers are detected, as in the attached patch.  This only affects the CMakeDetermineCXXCompiler.cmake module.
Comment 1 Ed Maste freebsd_committer 2015-10-15 17:55:24 UTC
We should encourage upstream to do this also
Comment 2 Raphael Kubo da Costa freebsd_committer 2015-11-17 18:54:18 UTC
I think I'm still missing some context. Bug 200475 was about removing CC; if CMake worked fine in that case, which problem is it solving here (ie. with CC still present)? Is there a plan to make CC != c++?

Also, instead of changing CMakeDetermineCXXCompiler.cmake, doesn't adding a Modules/Platform/FreeBSD-CXX.cmake similar to the Linux one also solve the problem you are trying to fix?
Comment 3 Dimitry Andric freebsd_committer 2015-11-17 19:02:12 UTC
(In reply to Raphael Kubo da Costa from comment #2)
> I think I'm still missing some context. Bug 200475 was about removing CC; if
> CMake worked fine in that case, which problem is it solving here (ie. with
> CC still present)? Is there a plan to make CC != c++?

The plan is to remove /usr/bin/CC in head.  However, on older branches, /usr/bin/CC will still exist.  In my opinion, cmake should prefer calling "c++" over "CC", if the former is available, that is all.


> Also, instead of changing CMakeDetermineCXXCompiler.cmake, doesn't adding a
> Modules/Platform/FreeBSD-CXX.cmake similar to the Linux one also solve the
> problem you are trying to fix?

Yes, but why would that be better than just fixing the C++ compiler determination for all platforms?
Comment 4 Raphael Kubo da Costa freebsd_committer 2015-11-17 19:37:25 UTC
(In reply to Dimitry Andric from comment #3)
> (In reply to Raphael Kubo da Costa from comment #2)
> > I think I'm still missing some context. Bug 200475 was about removing CC; if
> > CMake worked fine in that case, which problem is it solving here (ie. with
> > CC still present)? Is there a plan to make CC != c++?
> 
> The plan is to remove /usr/bin/CC in head.  However, on older branches,
> /usr/bin/CC will still exist.  In my opinion, cmake should prefer calling
> "c++" over "CC", if the former is available, that is all.

I see. But is there any downside to using CC if it's available? I'm trying to think from an upstream perspective, to whom a commit changing the order with no effects might seem unnecessary.

> > Also, instead of changing CMakeDetermineCXXCompiler.cmake, doesn't adding a
> > Modules/Platform/FreeBSD-CXX.cmake similar to the Linux one also solve the
> > problem you are trying to fix?
> 
> Yes, but why would that be better than just fixing the C++ compiler
> determination for all platforms?

I'm not sure if there's anything to be fixed in the first place, especially if you send it upstream and this changes behavior in all platforms CMake supports. I'm again assuming this is something upstreamable that either you or I will send to the appropriate list.
Comment 5 Dimitry Andric freebsd_committer 2015-11-17 19:54:00 UTC
(In reply to Raphael Kubo da Costa from comment #4)
...
> I see. But is there any downside to using CC if it's available? I'm trying
> to think from an upstream perspective, to whom a commit changing the order
> with no effects might seem unnecessary.

No, if CC exists it should behave the same as c++.  But CC is simply non-standard, and should not be used.  From the beginning, CMake should really have used c++ over CC.

...
> I'm not sure if there's anything to be fixed in the first place, especially
> if you send it upstream and this changes behavior in all platforms CMake
> supports. I'm again assuming this is something upstreamable that either you
> or I will send to the appropriate list.

Yeah, this should probably go upstream instead of in our port.
Comment 6 Raphael Kubo da Costa freebsd_committer 2015-11-18 09:25:01 UTC
OK, so can you send a patch to the cmake-developers mailing list with your proposal?
Comment 7 Raphael Kubo da Costa freebsd_committer 2015-12-22 12:06:40 UTC
Reassigning to submitter; there isn't much for kde@ to do here.
Comment 8 groot 2017-06-15 10:02:09 UTC
The very old CMake commit referenced here does two things:
 - defaults the C++ compiler to "CC" if nothing else sets it up
 - sets up linux, and a bunch of others, to use g++ or c++

A simple and straightforward way to avoid the use of CC as C++ compiler, is to add FreeBSD to the family of platforms that take the second path. This is 3 lines of CMake code in Modules/Platforms.

I've got this lined up for the (future) CMake 3.9 update, and will try to upstream it as well.
Comment 9 Raphael Kubo da Costa freebsd_committer 2017-09-27 09:29:18 UTC
Ade upstreamed not very long ago: https://gitlab.kitware.com/cmake/cmake/commit/a0508dee933fd4dca1020e54299844cd65a13fe2

And we've been shipping this since we updated CMake in the ports tree to 3.9.2.