Skip to content

Ignore compatible --disable options in configure#10962

Merged
dra27 merged 3 commits intoocaml:trunkfrom
dra27:configure-options
Feb 22, 2022
Merged

Ignore compatible --disable options in configure#10962
dra27 merged 3 commits intoocaml:trunkfrom
dra27:configure-options

Conversation

@dra27
Copy link
Copy Markdown
Member

@dra27 dra27 commented Jan 28, 2022

There will never be naked pointers again - for compatibility, we should keep the define for NO_NAKED_POINTERS in m.h and NAKED_POINTERS=false in Makefile.config.in, but there's no value in any of the rest of the codebase using it, which the first commit cleans.

I believe the update to the comment for Obj.reachable_words is correct?

Finally, when an option is removed from configuration, we keep the AC_ARG_ENABLE because it is clearer to explain to the user that the option requested no longer exists than to allow autoconf's default behaviour for an unrecognised option. This was done previously with the removal of vmthreads, spacetime and the graphics library.

The code used displayed an error for both --disable-foo and --enable-foo. However, there's no need to display an error for the --disable-foo parameter, since that's just being explicit about the new "default". This probably didn't come up with the previous three because graphics was trivially disabled on Unix by not having the libX11 headers (which are often not there by default anyway), vmthreads was unused and spacetime was off by default and so the --disable- forms were just less commonly used.

However, this isn't so true for CI-cache-saving systems which use options like --disable-bigarray-lib to squeeze a few more kilobytes out of freely available cache quotas. This commit tweaks the m4sh so that --disable-spacetime, --disable-naked-pointers, --disable-naked-pointers-checker, --disable-vmthreads, --disable-graph-lib and --disable-bigarray-lib are now silently ignored.

This completes #10831 (comment)

dra27 added 3 commits January 28, 2022 14:19
- Ensure NO_NAKED_POINTERS is always defined as 1 in m.h
- Propagate NAKED_POINTERS=false throughout the build and remove all
  uses of the variable
- Remove the naked_pointers ocamltest action and the tests which relied
  on it
Passing --disable-spacetime, --disable-naked-pointers,
--disable-naked-pointers-checker, --disable-vmthreads,
--disable-graph-lib and --disable-bigarray-lib to configure merely
make explicit the default for 5.00 and should not cause an error.
@dra27 dra27 added this to the 5.00.0 milestone Jan 28, 2022
@xavierleroy
Copy link
Copy Markdown
Contributor

Thank you for the cleanup work! I fully agree with the first two commits. I'm neutral about the third commit (ignoring configure options that are now the default). Why should OCaml users keep passing these options?

@dra27
Copy link
Copy Markdown
Member Author

dra27 commented Feb 1, 2022

It's not so much OCaml users, as some of its developers! I cannot remember exactly what it was, but I have certainly done a huge bisect in the past for something which required --enable-force-safe-string. In its present state, for the bisect you have to work out which side of this change you are as to whether you pass --enable-force-safe-string (etc.) or whether it's now the default vs just always passing that (automatically, as part of git bisect run). A variant of this is presently breaking FlexDLL's "trunk" build of OCaml because it passes --disable-bigarray-lib for 4.08+ (to save build time and, more importantly, precious AppVeyor cache quota).

So the rationale is that we want to keep the AC_ARG_ENABLE/AC_ARG_VAR for proper error messages and, at the cost of just one extra AS_IF, allow configure more simply by the odd developer by ignoring compatible options. The main thing is that all this only goes as far as configure - there's no vestige of this in the build system or, even worse, the compiler itself!

@xavierleroy
Copy link
Copy Markdown
Contributor

We need to make progress here. We have two unquestionable commits that are blocked by a third, opinionated commit. Could we get another opinion? Or just merge the first two commits right now.

@gasche
Copy link
Copy Markdown
Member

gasche commented Feb 18, 2022

Could we get another opinion?

Reviewing is hard, but opinions: any day!

I would agree with @dra27 that accepting irrelevant options that were relevant in the past is a good choice. (Of course, we should not silently accept options that are incompatible with the current state.) In general I fully trust @dra27's instincts on good UI for configuration across versions, tools, "windows core runtime libraries" and all that horrible stuff.

@dra27 dra27 merged commit f3ea33a into ocaml:trunk Feb 22, 2022
@dra27
Copy link
Copy Markdown
Member Author

dra27 commented Feb 22, 2022

Thanks, @gasche - I've gone with it as I'm just sorting out another part of FlexDLL for another task, and it'd be useful for that CI to work, too.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants