Skip to content

Silencing warnings on the 3.3.0 branch#21

Draft
cooljeanius wants to merge 13 commits intoiains:darwin-xtools-3-3-0from
cooljeanius:warning-silencing-3-3-0
Draft

Silencing warnings on the 3.3.0 branch#21
cooljeanius wants to merge 13 commits intoiains:darwin-xtools-3-3-0from
cooljeanius:warning-silencing-3-3-0

Conversation

@cooljeanius
Copy link

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:

  1. Bump CMake minimum to version supplied by cmake-bootstrap port in MacPorts
  2. Add libyaml as a git submodule
  3. Apply patches from the MacPorts port for darwin-xtools
  4. Run cproto -a on files that will let it work
  5. Add #ifndef guards around NDEBUG

Remaining tasks to do before I take this out of draft mode:

  • Figure out how to silence -Wenum-compare
  • Complete the more complex proto-izations
  • -Wformat
  • Only pass -lxar when linking, to avoid -Wunused-command-line-argument
  • Turn off -Wvla-cxx-extension, as there's not really any way to avoid it
  • Add something like automake's build verbosity control, to make it easier to see the remaining warnings

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
@iains
Copy link
Owner

iains commented Feb 27, 2026

As general comments

  • you are free to increase requirements downstream - but I have tried to keep to minimum versions on the various branches - to make it easier for legacy platforms to bootstrap.
  • please split out importing down-stream fixes as separate from clean-ups.

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).

@iains
Copy link
Owner

iains commented Feb 27, 2026

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)

@iains
Copy link
Owner

iains commented Feb 27, 2026

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants