Page MenuHomeFreeBSD

Retire WITHOUT_CXX option
Needs ReviewPublic

Authored by emaste on Wed, Nov 24, 9:30 PM.

Details

Reviewers
jhb
Summary

Several important base system components are written in C++, and the
WITHOUT_CXX option is not regularly tested and breaks often. Accept
this, and remove the option to build without C++ support.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

Agree with the idea in general.

Makefile.inc1
2977

Should this move up into the initial list a few lines earlier instead?

3145

Similarly, just merge this into the list above?

lib/Makefile
192

Should references to these libraries (e.g. ${_libcxxrt}) now just be expanded inline instead?

lib/libproc/Makefile
22

Maybe merge this with the LIBADD below?

tools/build/mk/OptionalObsoleteFiles.inc
3815

I'm a bit surprised there isn't a MK_TOOLCHAIN that covers removing these still? Maybe that would just remove clang though anyway, and not the libraries and headers.

Update with @jhb feedback (except OptionalObsoleteFiles)

emaste marked 4 inline comments as done and an inline comment as not done.Thu, Nov 25, 1:57 AM
emaste added inline comments.
Makefile.inc1
3145

done with rewrapping

tools/build/mk/OptionalObsoleteFiles.inc
3815

Hmm, need to double-check.

emaste added a subscriber: dim.
tools/build/mk/OptionalObsoleteFiles.inc
3815

I think there's no knob other than MK_CXX. These will now be installed always and will be just like libc or other /usr/include headers.

4207

but maybe we need to add these somewhere for turning off lib32

tools/build/mk/OptionalObsoleteFiles.inc
4207

No - ${MK_LIB32} == no is handled using find below

Posted a link to this review on the freebsd-hackers@ mailing list.

Discussed libc++ on IRC with @jrtc27. As a followup we may want to move libc++.so.1 from /usr/lib to /lib, and then stop linking devd statically. (See R10:9a4e73fe5ea6f6fe518de8cb3d23cf6e397c8896)

I think moving libc++ to /lib is fine, but should probably be a separate change. Fixing the lack of working MK_TOOLCHAIN in OptionalObsoleteFiles.inc also seems like it would be a separate change?

Hmm, on the OptionalObsoleteFiles.inc front, it does seem that MK_TOOLCHAIN=no does handle some of this as things like MK_CLANG have handling in OptionalObsoleteFiles.inc. It's true that we don't support MK_INCLUDES in OptionalObsoleteFiles.inc, but it might be nice to not regress 'make WITHOUT_TOOLCHAIN=yes delete-old' at least in terms of binaries like /usr/bin/CC and /usr/bin/c++. It may just mean moving those into the MK_CLANG block? Those two are installed today by usr.bin/clang/clang/Makefile. The cc1plus and g++ binaries are specific to GCC and should just be listed in the unconditional ObsoleteFiles.inc if they aren't already. (I just checked and the GCC ones are already handled correctly in ObsoleteFiles.inc).

This revision is now accepted and ready to land.Tue, Nov 30, 6:12 PM

I think moving libc++ to /lib is fine, but should probably be a separate change.

That one's D33123.

Fixing the lack of working MK_TOOLCHAIN in OptionalObsoleteFiles.inc also seems like it would be a separate change?

Yes, could be. I cleaned up cc1plus and g++ just now, in 1b9344add475.

We have the following groups of files to deal with:

  1. usr/bin/{CC,c++}
  2. lib/libcxxrt.so.1
  3. usr/{lib,lib32}/libc++*
  4. usr/{lib,lib32}/libcxxrt.*
  5. usr/include/c++/v1/*

MK_TOOLCHAIN indeed seems correct for #1. We can move #5 to a new MK_INCLUDES (with a comment that it's only the C++ includes at present). This leaves only the runtime lib components libcxxrt and libc++, in various combinations.

Yes, could be. I cleaned up cc1plus and g++ just now, in 1b9344add475.

We have the following groups of files to deal with:

  1. usr/bin/{CC,c++}
  2. lib/libcxxrt.so.1
  3. usr/{lib,lib32}/libc++*
  4. usr/{lib,lib32}/libcxxrt.*
  5. usr/include/c++/v1/*

MK_TOOLCHAIN indeed seems correct for #1. We can move #5 to a new MK_INCLUDES (with a comment that it's only the C++ includes at present). This leaves only the runtime lib components libcxxrt and libc++, in various combinations.

I would just move #1 to MK_CLANG since that if you build WITHOUT_CLANG they don't get installed (so they really should be part of MK_CLANG). #2-#4 I'm fine with losing. Maybe someday if we add MK_INCLUDES support that would cover #5. I don't think we need to fix #5 for now though. I would just move #1 into MK_CLANG in this commit and then call it a day.

This revision now requires review to proceed.Wed, Dec 1, 9:47 PM
tools/build/mk/OptionalObsoleteFiles.inc
1645

This one is already included in ${MK_TOOLCHAIN}

tools/build/mk/OptionalObsoleteFiles.inc
1645

Now removed in c3f345ae3c0f