Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Mon, 12 Feb 2024 14:09:49 GMT, Julian Waters wrote: >> I have verified that this works fine in the Oracle internal CI. >> >> Erik's point still stands: >>> I still think it would be prudent to verify this patch with all the >>> currently accepted versions of autoconf (2.69, 2.70, 2.71, 2.72). >> >> I think the easiest way to achieve this is to checkout the autoconf at these >> versions, and build it yourself. Iirc it was quite easy to build autoconf >> (anything else would be a shame and very bad PR for the project! :-o). >> >> I'm hoping you are willing to do this, since I believe this is a superior >> solution and I'd like to see it in mainline. (Otherwise, let me know and >> I'll try to squeeze in doing it.) > >> I have verified that this works fine in the Oracle internal CI. >> >> Erik's point still stands: >> >> > I still think it would be prudent to verify this patch with all the >> > currently accepted versions of autoconf (2.69, 2.70, 2.71, 2.72). >> >> I think the easiest way to achieve this is to checkout the autoconf at these >> versions, and build it yourself. Iirc it was quite easy to build autoconf >> (anything else would be a shame and very bad PR for the project! :-o). >> >> I'm hoping you are willing to do this, since I believe this is a superior >> solution and I'd like to see it in mainline. (Otherwise, let me know and >> I'll try to squeeze in doing it.) > > It's actually even easier to do on Windows than it might appear, since > MinGW's pacman system has caches that contain past package versions. I > wouldn't have to build it at all in fact, all I'd have to do is downgrade my > autoconf to past versions (I think I'm currently on 2.71). I know you're > probably very busy right now, so I'll spare you the chore of having to do > that by testing it on my end. That said, should I test autoconf on all > platforms too? That aside, I'm still a little unhappy that there is no formal > way to unregister an AC_DEFUN macro though :( > > By the way, I've left you something in the mail. Hope you have some time to > check it out! > @TheShermanTanker I think this is essentially done. All that needs are the > testing. Can you do it or do you want help with it? I'm able to do so myself, I've just been busy with university so far. I've only tested 2.71 and 2.72 though, 2.69 and 2.70 might still need testing. I'm still unhappy that I can't properly undefine the macros, as a side tangent - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1991874882
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Mon, 12 Feb 2024 14:09:49 GMT, Julian Waters wrote: > That said, should I test autoconf on all platforms too? No, that seems over the top. For this purpose, we must assume that all autoconf on all platforms behave the same. - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1938783176
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Mon, 12 Feb 2024 13:57:55 GMT, Magnus Ihse Bursie wrote: > I have verified that this works fine in the Oracle internal CI. > > Erik's point still stands: > > > I still think it would be prudent to verify this patch with all the > > currently accepted versions of autoconf (2.69, 2.70, 2.71, 2.72). > > I think the easiest way to achieve this is to checkout the autoconf at these > versions, and build it yourself. Iirc it was quite easy to build autoconf > (anything else would be a shame and very bad PR for the project! :-o). > > I'm hoping you are willing to do this, since I believe this is a superior > solution and I'd like to see it in mainline. (Otherwise, let me know and I'll > try to squeeze in doing it.) It's actually even easier to do on Windows than it might appear, since MinGW's pacman system has caches that contain past package versions. I wouldn't have to build it at all in fact, all I'd have to do is downgrade my autoconf to past versions (I think I'm currently on 2.71). I know you're probably very busy right now, so I'll spare you the chore of having to do that by testing it on my end. That said, should I test autoconf on all platforms too? That aside, I'm still a little unhappy that there is no formal way to unregister an AC_DEFUN macro though :( By the way, I've left you something in the mail. Hope you have some time to check it out! - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1938751180
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote: >> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted >> autoconf flags being added to the command line, and solves the issue by >> filtering out the added flags by force. This is not optimal however, as >> doing so leaves the autoconf message that the flags were added still >> displaying during the configure process, which is confusing. Instead, >> setting a couple of fields to disable the autoconf internals responsible for >> the unwanted flag is a cleaner solution > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Implement custom AC_PROG_CC and AC_PROG_CXX in util.m4 I have verified that this works fine in the Oracle internal CI. Erik's point still stands: > I still think it would be prudent to verify this patch with all the currently > accepted versions of autoconf (2.69, 2.70, 2.71, 2.72). I think the easiest way to achieve this is to checkout the autoconf at these versions, and build it yourself. Iirc it was quite easy to build autoconf (anything else would be a shame and very bad PR for the project! :-o). I'm hoping you are willing to do this, since I believe this is a superior solution and I'd like to see it in mainline. (Otherwise, let me know and I'll try to squeeze in doing it.) - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1938730535
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote: >> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted >> autoconf flags being added to the command line, and solves the issue by >> filtering out the added flags by force. This is not optimal however, as >> doing so leaves the autoconf message that the flags were added still >> displaying during the configure process, which is confusing. Instead, >> setting a couple of fields to disable the autoconf internals responsible for >> the unwanted flag is a cleaner solution > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Implement custom AC_PROG_CC and AC_PROG_CXX in util.m4 I'm not sure if I said so, but I think this looks good. As Erik said, it would be good to verify this with a few different autoconf versions. - Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17401#pullrequestreview-1851350151
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote: >> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted >> autoconf flags being added to the command line, and solves the issue by >> filtering out the added flags by force. This is not optimal however, as >> doing so leaves the autoconf message that the flags were added still >> displaying during the configure process, which is confusing. Instead, >> setting a couple of fields to disable the autoconf internals responsible for >> the unwanted flag is a cleaner solution > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Implement custom AC_PROG_CC and AC_PROG_CXX in util.m4 Correction: I checked the history, and you are correct. It was a change in autoconf version from 2.71 to 2.72 that caused this. - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1901235592
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Fri, 19 Jan 2024 21:17:20 GMT, Erik Joelsson wrote: > I would just like to point out that it was a change in autoconf behavior > that triggered this whole ordeal in the first place I'm not entirely sure that is the case. It might as well have been a latent bug that was triggered by changes in the environment, or the compiler, or something like that. I don't think we ever got to the bottom of what caused it. - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1901233554
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Fri, 19 Jan 2024 14:21:28 GMT, Julian Waters wrote: > Haha, thanks both. Though one thing has been annoying me ever since I wrote > this, it's the fact that no "AC_UNDEF" exists to erase macros defined by > AC_DEFUN. Overwriting macros like this, especially macros that are part of > the "autoconf standard library", is a little bit painful to me. On the other > hand, not like there is another way either... (I guess m4_undefine exists, > but that seems to be more for macros defined with m4_define, though I have > tried using it on macros defined by AC_DEFUN and it _did_ work) I don't think it's strange that they aren't duplicating existing m4 functionality. If you want to undefine macros you are already moving outside of the intended autoconf APIs so having to reach for direct m4 functionality would be expected. - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1901129889
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Fri, 19 Jan 2024 14:14:46 GMT, Magnus Ihse Bursie wrote: > In contrast with Erik I'm not so worried about future breakage. Autoconf has > basically stalled in development since decades. If someone were to pick up > development again (like what happened with GNU Make) we will surely see signs > of activity long before this breaks. And if that happens, we can just file a > bug on autoconf instead of trying to work around the broken behaviour, right? > 路 If you are ok with this, then I am too, just wanted to be thorough with possible concerns. I would just like to point out that it was a change in autoconf behavior that triggered this whole ordeal in the first place, so saying nothing is happening doesn't exactly seem true. The way I see it, if they change one of the sub/internal macros in an incompatible way, then we will just have to keep inlining the old versions of such macros in our configure script to work around it. I still think it would be prudent to verify this patch with all the currently accepted versions of autoconf (2.69, 2.70, 2.71, 2.72). - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1901126832
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote: >> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted >> autoconf flags being added to the command line, and solves the issue by >> filtering out the added flags by force. This is not optimal however, as >> doing so leaves the autoconf message that the flags were added still >> displaying during the configure process, which is confusing. Instead, >> setting a couple of fields to disable the autoconf internals responsible for >> the unwanted flag is a cleaner solution > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Implement custom AC_PROG_CC and AC_PROG_CXX in util.m4 Haha, thanks both. Though one thing has been annoying me ever since I wrote this, it's the fact that no "AC_UNDEF" exists to erase macros defined by AC_DEFUN. Overwriting macros like this, especially macros that are part of the "autoconf standard library", is a little bit painful to me. On the other hand, not like there is another way either... (I guess m4_undefine exists, but that seems to be more for macros defined with m4_define, though I have tried using it on macros defined by AC_DEFUN and it _did_ work) - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1900508158
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote: >> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted >> autoconf flags being added to the command line, and solves the issue by >> filtering out the added flags by force. This is not optimal however, as >> doing so leaves the autoconf message that the flags were added still >> displaying during the configure process, which is confusing. Instead, >> setting a couple of fields to disable the autoconf internals responsible for >> the unwanted flag is a cleaner solution > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Implement custom AC_PROG_CC and AC_PROG_CXX in util.m4 I agree with Erik, this looks interesting. I also like the benefit of transparency that it brings, breaking down the black box of autoconf a bit more. In contrast with Erik I'm not so worried about future breakage. Autoconf has basically stalled in development since decades. If someone were to pick up development again (like what happened with GNU Make) we will surely see signs of activity long before this breaks. And if that happens, we can just file a bug on autoconf instead of trying to work around the broken behaviour, right? 路 I would like to take this PR for a spin on a bunch of machines/environments, though, to see that it does not fail obviously on any of them. - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1900497417
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Fri, 19 Jan 2024 01:22:27 GMT, Julian Waters wrote: > I found out that the issue of having AC_PROG_CC and AC_PROG_CXX being called > by AC_REQUIRE can be solved by directly overwriting them in util.m4, rather > than providing our own UTIL_PROG_CC and so on. Unsure how satisfactory this > is, but I have here a stripped down version of both that omits: > > For AC_PROG_CC > > * The default check from a list of compilers if the compilers to search for > list is empty, this now means AC_PROG_CC has to always be called with the > argument at all times. We always do this, so shouldn't be a problem > * The check whether the compiler supports GNU C. This shouldn't be relevant > * The ill fated check that adds -std=gnu11. This was the one that the other > issue wanted to get rid of > > For AC_PROG_CXX > > * Similarly, the default check from a list of compilers if the compilers to > search for list is empty, and the check for CCC if it is set (We don't use > CCC as fair as I can tell), this now means AC_PROG_CXX has to always be > called with the argument at all times. We again always do this, so shouldn't > be a problem > * The check whether the compiler supports GNU C++. This shouldn't be relevant > * The ill fated check that adds -std=gnu++11. This is also the one that the > other issue wanted to get rid of > > Notably, I left the check that checks if the compiler accepts -g in there, as > I was unsure if we need it or not. I also tried removing the check for the > object file extension, but apparently autoconf needs that to function > properly. The exe file extension check is misleadingly named, because in > actuality all of AC_PROG_CC and AC_PROG_CXX's functionality is in it,and it's > also likely required for autoconf to work properly This does look like an interesting solution and far smaller than I had anticipated. The risk is that we start depending on autoconf internals that may change in future versions. We would also need to validate this solution against all currently supported versions. At least I'm assuming that macros starting with `_` aren't part of the public API. - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1900476220
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote: >> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted >> autoconf flags being added to the command line, and solves the issue by >> filtering out the added flags by force. This is not optimal however, as >> doing so leaves the autoconf message that the flags were added still >> displaying during the configure process, which is confusing. Instead, >> setting a couple of fields to disable the autoconf internals responsible for >> the unwanted flag is a cleaner solution > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Implement custom AC_PROG_CC and AC_PROG_CXX in util.m4 I found out that the issue of having AC_PROG_CC and AC_PROG_CXX being called by AC_REQUIRE can be solved by directly overwriting them in util.m4, rather than providing our own UTIL_PROG_CC and so on. Unsure how satisfactory this is, but I have here a stripped down version of both that omits: For AC_PROG_CC - The default check from a list of compilers if the compilers to search for list is empty, this now means AC_PROG_CC has to always be called with the argument at all times. We always do this, so shouldn't be a problem - The check whether the compiler supports GNU C. This shouldn't be relevant - The ill fated check that adds -std=gnu11. This was the one that the other issue wanted to get rid of For AC_PROG_CXX - Similarly, the default check from a list of compilers if the compilers to search for list is empty, and the check for CCC if it is set (We don't use CCC as fair as I can tell), this now means AC_PROG_CXX has to always be called with the argument at all times. We again always do this, so shouldn't be a problem - The check whether the compiler supports GNU C++. This shouldn't be relevant - The ill fated check that adds -std=gnu++11. This is also the one that the other issue wanted to get rid of Notably, I left the check that checks if the compiler accepts -g in there, as I was unsure if we need it or not. I also tried removing the check for the object file extension, but apparently autoconf needs that to function properly. The exe file extension check is misleadingly named, because in actuality all of AC_PROG_CC and AC_PROG_CXX's functionality is in it,and it's also likely required for autoconf to work properly - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1899483894
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]
> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted > autoconf flags being added to the command line, and solves the issue by > filtering out the added flags by force. This is not optimal however, as doing > so leaves the autoconf message that the flags were added still displaying > during the configure process, which is confusing. Instead, setting a couple > of fields to disable the autoconf internals responsible for the unwanted flag > is a cleaner solution Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Implement custom AC_PROG_CC and AC_PROG_CXX in util.m4 - Changes: - all: https://git.openjdk.org/jdk/pull/17401/files - new: https://git.openjdk.org/jdk/pull/17401/files/1e37103f..8d8d3749 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17401=06 - incr: https://webrevs.openjdk.org/?repo=jdk=17401=05-06 Stats: 64 lines in 1 file changed: 64 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17401/head:pull/17401 PR: https://git.openjdk.org/jdk/pull/17401
