Ralf Wildenhues <ralf.wildenh...@gmx.de> writes: > * Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 07:31:04PM CEST: >> Ralf Wildenhues writes: >> > Do you have, or are working on, an Automake patch for Go support? >> >> I do not have an automake patch, although that is a logical next step. >> I've been using libtool with a Makefile.am which uses this definition: >> >> LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GCCGO) $(INCLUDES) \ >> $(AM_GOFLAGS) $(GOFLAGS) >> >> and then runs $(LTGOCOMPILE) as needed. Adding Go support to automake >> may be a little tricky as Go requires a slightly different compilation >> model: you must pass all files that are in the same package to the >> compiler at once. You can't compile them separately. > > That is not a big problem per se. However, how would you implement > build parallelism? Inside gccgo? Should it eventually have jobserver > support, received from make?
Note that when I say a package I don't mean an entire program. A package in Go is like a single library, or what some languages call a module. E.g., the standard Go library has a fmt package, an os package, a math package, etc. When compiling Go, you must pass all files in a package to the compiler at the same time. In principle part of the compilation of a single package could be parallelized, but not in any simple or straightforward way. You can group many different Go packages together into a single .a or .so file. > What if files reside in subdirs (of the current directory, or of > $srcdir), will objects be created in subdirs or in the current directory > (and how would we avoid creation of files below $srcdir in a VPATH > build, given that $srcdir is a concept not known to the compiler a > priori)? Or maybe it has no objects at all? Only one object file is created for each package. It can go wherever. > Can the user split up large projects into multiple pieces, either by > separate Makefile.am files for separate directories, or somehow > separately compiling the set of sources in one directory, maybe by > library or by program compiled? Sure. > If the latter is to be supported, then > things like overlapping sources become a problem (i.e., both libfoo and > libbar use baz.o). That can not happen, because baz.go can only be in one package. Ian