| Message ID | mcrpqrpbssb.fsf@google.com |
|---|---|
| State | New |
| Headers | show |
* Ian Lance Taylor wrote on Sat, Jan 22, 2011 at 03:01:40AM CET: > If anybody knows of a simple way to use automake with files > that may or may not exist, please let me know. I'd prefer to avoid > configure tests since they separate the test and the use in a way that I > find hard to maintain over time. Hmm, you can if COND foo_SOURCES += bar.go endif or you can foo_SOURCES = $(computed) EXTRA_foo_SOURCES = bar1.go bar2.go bar3.go where $(computed) must come from the second set. If you want to use only Posix make, then you need to have at least some bit of computation at configure time for this. Hope that helps. Cheers, Ralf
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes: > * Ian Lance Taylor wrote on Sat, Jan 22, 2011 at 03:01:40AM CET: >> If anybody knows of a simple way to use automake with files >> that may or may not exist, please let me know. I'd prefer to avoid >> configure tests since they separate the test and the use in a way that I >> find hard to maintain over time. > > Hmm, you can > > if COND > foo_SOURCES += bar.go > endif > > or you can > > foo_SOURCES = $(computed) > EXTRA_foo_SOURCES = bar1.go bar2.go bar3.go > > where $(computed) must come from the second set. > > If you want to use only Posix make, then you need to have at least some > bit of computation at configure time for this. Thanks, I know about those possibilities, but they aren't what I want, because they require me to determine whether the files exist in the configure script and to then use that determination in the Makefile. I don't want to split things up that way. I want to say something like foo_SOURCES = `test -f f.c && echo f.c` Ian
* Ian Lance Taylor wrote on Sun, Jan 23, 2011 at 06:23:35AM CET: > Ralf Wildenhues writes: > > * Ian Lance Taylor wrote on Sat, Jan 22, 2011 at 03:01:40AM CET: > >> If anybody knows of a simple way to use automake with files > >> that may or may not exist, please let me know. I'd prefer to avoid > >> configure tests since they separate the test and the use in a way that I > >> find hard to maintain over time. > > if COND > > foo_SOURCES += bar.go > > endif > > > > or you can > > > > foo_SOURCES = $(computed) > > EXTRA_foo_SOURCES = bar1.go bar2.go bar3.go > Thanks, I know about those possibilities, but they aren't what I want, > because they require me to determine whether the files exist in the > configure script and to then use that determination in the Makefile. I > don't want to split things up that way. I want to say something like > > foo_SOURCES = `test -f f.c && echo f.c` That doesn't work with the current dependency tracking machinery; it needs to know the list of files at automake time in order to include the relevant .Po and .Plo files in the Makefile. This is something we may be able to address once we have machinery in place to emit GNU make-specific code, and this Makefile is required to work with GNU make only. Sorry, Ralf
On Fri, Jan 21, 2011 at 8:01 PM, Ian Lance Taylor <iant@google.com> wrote: > This trivial libgo patch adds a file to hold SPARC RTEMS specific > information to the syscalls subdirectory. There is nothing in there at > present. If anybody knows of a simple way to use automake with files > that may or may not exist, please let me know. I'd prefer to avoid > configure tests since they separate the test and the use in a way that I > find hard to maintain over time. Anyhow, bootstrapped and ran Go > testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Out of curiosity, why is there a need for architecture specific Go syscalls for RTEMS? We use newlib and are a link-in library OS. RTEMS doesn't have a trap interface. We have avoided architecture specific files in the Ada run-time. All the ones that exist now are empty and I would expect that to continue through the dozen or so architectures RTEMS supports. --joel > Ian > >
Joel Sherrill <joel.sherrill@gmail.com> writes: > On Fri, Jan 21, 2011 at 8:01 PM, Ian Lance Taylor <iant@google.com> wrote: >> This trivial libgo patch adds a file to hold SPARC RTEMS specific >> information to the syscalls subdirectory. There is nothing in there at >> present. If anybody knows of a simple way to use automake with files >> that may or may not exist, please let me know. I'd prefer to avoid >> configure tests since they separate the test and the use in a way that I >> find hard to maintain over time. Anyhow, bootstrapped and ran Go >> testsuite on x86_64-unknown-linux-gnu. Committed to mainline. > > Out of curiosity, why is there a need for architecture specific > Go syscalls for RTEMS? We use newlib and are a link-in library > OS. RTEMS doesn't have a trap interface. We have avoided > architecture specific files in the Ada run-time. > > All the ones that exist now are empty and I would expect that > to continue through the dozen or so architectures RTEMS supports. Yes, for RTEMS, right now, I agree. The problem is that for some CPU/OS combinations, there does need to be some specific support, e.g., syscall_linux_386.go. So it would be nice to have a clean and simple way to determine, in the Makefile, whether there is a CPU/OS specific file that needs to be built. I guess I should give up and do the test in libgo/configure.ac. Ian
Index: libgo/syscalls/syscall_rtems_sparc.go =================================================================== --- libgo/syscalls/syscall_rtems_sparc.go (revision 0) +++ libgo/syscalls/syscall_rtems_sparc.go (revision 0) @@ -0,0 +1,7 @@ +// syscall_rtems_sparc.go -- RTEMS SPARC specific syscall interface. + +// Copyright 2011 The Go Authors. All rights reserved. +// Use of this source code is governed by a BSD-style +// license that can be found in the LICENSE file. + +package syscall