Silencing warnings on the 3.3.0 branch - #21
Conversation
CMake Deprecation Warning at CMakeLists.txt:3 (cmake_minimum_required): Compatibility with CMake < 3.10 will be removed from a future version of CMake. Update the VERSION argument <min> value. Or, use the <min>...<max> syntax to tell CMake that the project requires at least <min> but has been updated to work with policies introduced by <max> or earlier.
Drop minimum required version back down a bit cmake-bootstrap port in MacPorts is 3.9.6
Save a copy of the command-line I used to configure
add path to libyaml
silence warnings about prototypes
or more specifically, I ran: `find . -name '*.c' -print | xargs cproto -a` ...and then backed out the changes that caused build failures, or showed mangling of GNU __attribute__ syntax in the diff
the ones remaining in i386.c are a bit trickier
|
As general comments
Why do we need to import libyaml? This is especially important on xtools-0.7.0 since we want that to be buildable using only apple gcc-4.2.1 (which limits the cmake version to 3.9.6). It is a great objective to clean up the code - but that should be done to improve maintainability - in the end, we need to be able to take patches between imported versions of Apple's code (so that the cleanups kinda need to be applied uniformly to the imported code). |
|
also I would really really like to avoid git submodules - since they do not work well with trying to checkout some version of a composite project (it's a problem with the Apple OSS code releases - it means basically building a separate checkout for each edition - one cannot use git work trees) |
|
you should also be aiming to make 0 changes to any of the released Xcode or Makefiles from Apple - the whole point of using cmake is to keep the build completely separate from the assumptions of the Apple build system. |
|
@cooljeanius FWIW, xtools in MacPorts are unmaintained and reduced to a single branch, which is also a wrong pick for some cases. My port is probably more “correct” (and it also incorporates Kirill’s earlier work, so MacPorts version is fully redundant). |
What work is this and was there a PR for it made here? |
|
macports/macports-ports@761f9b4 @catap Kirill, could you please join us here? |
|
I guess the same comments I made to @cooljeanius apply - what we need is single patches that fix specific issues - and for now, constrain those to ones that affect the 0.7.0 branch - since that's the most complete and is targeting legacy systems. (At some point, I will try to take the improvements forward - especially the ones that affect debug data, but - for now - let's focus on applying any changes needed to make 0.7.0 robust) I don't think it's going to be possible to have a "one size fits all" for this set - because we have a conflict between needing a C++98 codebase to bootstrap the toolchain with Apple-gcc-4.2.1 and needing C++11 or later for later Xcode sources. |
3 participants
These are the changes I had to make to get a successful build on Tahoe, along with some additional warning silencing to make it easier to find actual errors in the build output. Specifically:
cmake-bootstrapport in MacPortscproto -aon files that will let it work#ifndefguards aroundNDEBUGRemaining tasks to do before I take this out of draft mode:
-Wenum-compare-Wformat-lxarwhen linking, to avoid-Wunused-command-line-argument-Wvla-cxx-extension, as there's not really any way to avoid it