| Message ID | CAOyqgcUFmBppk_jDpeO+raujT5P7eNtGrNVH3HbhnSWGRWtbUQ@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 10/23/2014 04:36 AM, Ian Taylor wrote: > This patch to the top level GCC configure script disables the go > languages on some systems where it is known to not work. Bootstrapped > on x86_64-unknown-gnu-linux. > > OK for mainline? > > Ian > > 2014-10-22 Ian Lance Taylor <iant@google.com> > > * configure.ac: Disable the Go frontend on systems where it is known > to not work. > * configure: Regenerate. > I think it'd be better if knowledge specific to subdirs was pushed down to the subdirs, rather than being kept in the top level, in the direction of how we disable libatomic, libsanitizer, etc. That is, by sourcing something in the subdir to get back the info top level needs. With that in place, changes to the set of supported hosts/targets/configurations no longer needs to be synchronized between the projects that use the top-level scripts. In the specific case of languages, it seems to be we already have such a script. E.g.: # First scan to see if an enabled language requires some other language. # We assume that a given config-lang.in will list all the language # front ends it requires, even if some are required indirectly. for lang_frag in ${srcdir}/gcc/*/config-lang.in .. ; do case ${lang_frag} in Each config-lang.in sets some output variables. For the case of a language being unsupported for some reason, we'd declare that the lang fragments can specify one more output variable, simply called "unsupported", and then in in go's gcc/go/config-lang.in, we'd add: # Disable the go frontend on systems where it is known to not work. case "${target}" in *-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*) unsupported=true ;; esac Then back in the top level, near where we do: # Disable languages that need other directories if these aren't available. for i in $subdir_requires; do test -f "$srcdir/gcc/$i/config-lang.in" && continue ... We'd handle the "unsupported" variable. WDYT? Thanks, Pedro Alves
On Thu, Oct 23, 2014 at 8:27 AM, Pedro Alves <palves@redhat.com> wrote: > > I think it'd be better if knowledge specific to subdirs was pushed down to > the subdirs, rather than being kept in the top level, in the direction > of how we disable libatomic, libsanitizer, etc. That is, by sourcing > something in the subdir to get back the info top level needs. With that > in place, changes to the set of supported hosts/targets/configurations > no longer needs to be synchronized between the projects that use > the top-level scripts. > > In the specific case of languages, it seems to be we already have such > a script. E.g.: > > # First scan to see if an enabled language requires some other language. > # We assume that a given config-lang.in will list all the language > # front ends it requires, even if some are required indirectly. > for lang_frag in ${srcdir}/gcc/*/config-lang.in .. ; do > case ${lang_frag} in > > Each config-lang.in sets some output variables. For the case of a > language being unsupported for some reason, we'd declare that > the lang fragments can specify one more output variable, simply called > "unsupported", and then in in go's gcc/go/config-lang.in, we'd add: > > # Disable the go frontend on systems where it is known to not work. > case "${target}" in > *-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*) > unsupported=true > ;; > esac > > Then back in the top level, near where we do: > > # Disable languages that need other directories if these aren't available. > for i in $subdir_requires; do > test -f "$srcdir/gcc/$i/config-lang.in" && continue > ... > > We'd handle the "unsupported" variable. My patch was, of course, just building on the existing unsupported_languages support. You are suggesting that we move that support from the top level configure script to the language-specific config-lang.in scripts. That change sounds fine to me. Ian
On 10/23/2014 04:31 PM, Ian Taylor wrote: > On Thu, Oct 23, 2014 at 8:27 AM, Pedro Alves <palves@redhat.com> wrote: >> >> I think it'd be better if knowledge specific to subdirs was pushed down to >> the subdirs, rather than being kept in the top level, in the direction >> of how we disable libatomic, libsanitizer, etc. That is, by sourcing >> something in the subdir to get back the info top level needs. With that >> in place, changes to the set of supported hosts/targets/configurations >> no longer needs to be synchronized between the projects that use >> the top-level scripts. >> >> In the specific case of languages, it seems to be we already have such >> a script. E.g.: >> >> # First scan to see if an enabled language requires some other language. >> # We assume that a given config-lang.in will list all the language >> # front ends it requires, even if some are required indirectly. >> for lang_frag in ${srcdir}/gcc/*/config-lang.in .. ; do >> case ${lang_frag} in >> >> Each config-lang.in sets some output variables. For the case of a >> language being unsupported for some reason, we'd declare that >> the lang fragments can specify one more output variable, simply called >> "unsupported", and then in in go's gcc/go/config-lang.in, we'd add: >> >> # Disable the go frontend on systems where it is known to not work. >> case "${target}" in >> *-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*) >> unsupported=true >> ;; >> esac >> >> Then back in the top level, near where we do: >> >> # Disable languages that need other directories if these aren't available. >> for i in $subdir_requires; do >> test -f "$srcdir/gcc/$i/config-lang.in" && continue >> ... >> >> We'd handle the "unsupported" variable. > > My patch was, of course, just building on the existing > unsupported_languages support. You are suggesting that we move that > support from the top level configure script to the language-specific > config-lang.in scripts. AFAICS no target in the top level disables go yet, so we could IMO do the config-lang.in mechanism without moving any of the existing target checks for other languages. It'd be a small change that way. As bonus, I think you wouldn't need approval for further changes to the set of go supported systems (though that may not change often). My .02c. > That change sounds fine to me. Thanks, Pedro Alves
On 10/22/14 21:36, Ian Taylor wrote: > This patch to the top level GCC configure script disables the go > languages on some systems where it is known to not work. Bootstrapped > on x86_64-unknown-gnu-linux. > > OK for mainline? > > Ian > > 2014-10-22 Ian Lance Taylor <iant@google.com> > > * configure.ac: Disable the Go frontend on systems where it is known > to not work. > * configure: Regenerate. Yea. This would seem to fall under the obvious rule to me. Add to that your status as "Mr. go", it's a no-brainer. :-) jeff
On Thu, Oct 23, 2014 at 8:39 AM, Pedro Alves <palves@redhat.com> wrote: > On 10/23/2014 04:31 PM, Ian Taylor wrote: >> >> My patch was, of course, just building on the existing >> unsupported_languages support. You are suggesting that we move that >> support from the top level configure script to the language-specific >> config-lang.in scripts. > > AFAICS no target in the top level disables go yet, so we > could IMO do the config-lang.in mechanism without moving any of > the existing target checks for other languages. It'd be a small > change that way. That sounds like setting up yet another incomplete transition. I would strongly prefer to have all languages act the same way. Ian
Hi Ian, On Wed, 2014-10-22 20:36:53 -0700, Ian Taylor <iant@golang.org> wrote: > This patch to the top level GCC configure script disables the go > languages on some systems where it is known to not work. Bootstrapped > on x86_64-unknown-gnu-linux. I don't have a clue here, but in what way is Go broken for these targets? Bacause this patch "breaks" a number of targets mentioned in contrib/config-list.mk. Maybe Go didn't work on these, but it at least built. Is it FUBAR there? Or just little fixes needed? MfG, JBG
On Mon, Oct 27, 2014 at 8:06 AM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote: > > On Wed, 2014-10-22 20:36:53 -0700, Ian Taylor <iant@golang.org> wrote: >> This patch to the top level GCC configure script disables the go >> languages on some systems where it is known to not work. Bootstrapped >> on x86_64-unknown-gnu-linux. > > I don't have a clue here, but in what way is Go broken for these > targets? Bacause this patch "breaks" a number of targets mentioned in > contrib/config-list.mk. Maybe Go didn't work on these, but it at > least built. Is it FUBAR there? Or just little fixes needed? I'm not sure exactly what you mean by "breaks," here, as Go is never in the set of default languages. It should only break builds that are using --enable-languages=go. And for those targets, the Go support has never worked, so they were already broken. For Darwin I expect that only small fixes are needed. This is http://gcc.gnu.org/PR46986. For Windows the compiler probably only needs small fixes, but the libgo build will need a bunch of support, particularly in the syscall package. The support for Windows is mostly there in the code, because it is in the master Go library, but it's not being built for libgo. For AIX I'm not sure. It's probably not too much work. Ian
On Mon, 2014-10-27 08:19:34 -0700, Ian Taylor <iant@golang.org> wrote: > On Mon, Oct 27, 2014 at 8:06 AM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote: > > On Wed, 2014-10-22 20:36:53 -0700, Ian Taylor <iant@golang.org> wrote: > > > This patch to the top level GCC configure script disables the go > > > languages on some systems where it is known to not work. Bootstrapped > > > on x86_64-unknown-gnu-linux. > > > > I don't have a clue here, but in what way is Go broken for these > > targets? Bacause this patch "breaks" a number of targets mentioned in > > contrib/config-list.mk. Maybe Go didn't work on these, but it at > > least built. Is it FUBAR there? Or just little fixes needed? > > I'm not sure exactly what you mean by "breaks," here, as Go is never > in the set of default languages. It should only break builds that are > using --enable-languages=go. And for those targets, the Go support > has never worked, so they were already broken. With its initial commit in 2010, Joern had Go in the --enable-languages list in contrib/config-list.mk . This used to work (read: build succeeded), even if Go wouldn't work (or wasn't built silently, I didn't check.) With this slight change in behavior, we'd probably fix config-list.mk to reflect these targets where Go would lead to a configury failure early. MfG, JBG
On Mon, Oct 27, 2014 at 9:02 AM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote: > On Mon, 2014-10-27 08:19:34 -0700, Ian Taylor <iant@golang.org> wrote: >> On Mon, Oct 27, 2014 at 8:06 AM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote: >> > On Wed, 2014-10-22 20:36:53 -0700, Ian Taylor <iant@golang.org> wrote: >> > > This patch to the top level GCC configure script disables the go >> > > languages on some systems where it is known to not work. Bootstrapped >> > > on x86_64-unknown-gnu-linux. >> > >> > I don't have a clue here, but in what way is Go broken for these >> > targets? Bacause this patch "breaks" a number of targets mentioned in >> > contrib/config-list.mk. Maybe Go didn't work on these, but it at >> > least built. Is it FUBAR there? Or just little fixes needed? >> >> I'm not sure exactly what you mean by "breaks," here, as Go is never >> in the set of default languages. It should only break builds that are >> using --enable-languages=go. And for those targets, the Go support >> has never worked, so they were already broken. > > With its initial commit in 2010, Joern had Go in the > --enable-languages list in contrib/config-list.mk . This used to work > (read: build succeeded), even if Go wouldn't work (or wasn't built > silently, I didn't check.) > > With this slight change in behavior, we'd probably fix > config-list.mk to reflect these targets where Go would lead to a > configury failure early. I think changing config-list.mk is appropriate. I added this patch to the top-level configure script because someone observed that it was annoying to configure GCC for Darwin with --enable-languages=go, have the whole build succeed, and only then discover that attempts to build Go programs failed with obscure error messages. That does not serve our users. Ian
Index: configure.ac =================================================================== --- configure.ac (revision 216522) +++ configure.ac (working copy) @@ -772,6 +772,13 @@ case "${target}" in ;; esac +# Disable the go frontend on systems where it is known to not work. +case "${target}" in +*-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*) + unsupported_languages="$unsupported_languages go" + ;; +esac + # Disable libgo for some systems where it is known to not work. # For testing, you can easily override this with --enable-libgo. if test x$enable_libgo = x; then