Re: PATCH RFA: Add Go support
Hello Ian, let's move this part of the discussion to the automake@ list. And sorry for delays, I cannot help that ATM. * Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 09:58:49PM CEST: Ralf Wildenhues 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. OK. So IIUC one example dependency graph would be something like this: ( sin.go cos.go exp.go ) - math.OBJEXT - libfem.so ( grid.go solver.go )- sub/pdesolve.OBJEXT ---^ where the sets of .go files are distinct, the sets of object files (packages) cannot be derived from their inputs (neither their names nor their contents?) but rather specified only in the makefile, and objects are subsumed in (static or shared) libraries or in programs as usual. OBJEXT may be o or obj (for w32) or lo (for libtool). We need a bit of new notation for this, and we need to teach automake about languages that shouldn't have renamed objects even in the presence of per-object flags. With libtool, naming wouldn't sound so hard, one could just go with something like: lib_LTLIBRARIES = libfem.la libfem_la_LIBADD = math.lo sub/pdesolve.lo # yes, _LIBADD math_lo_SOURCES = sin.go cos.go exp.go sub_pdesolve_lo_SOURCES = grid.go solver.go Without libtool, we could canonify $(OBJEXT) as _o: bin_PROGRAMS = fem fem_LDADD = math.$(OBJEXT) sub/pdesolve.$(OBJEXT) math_o_SOURCES = sin.go cos.go exp.go sub_pdesolve_o_SOURCES = grid.go solver.go but that looks fairly ugly to me already. Better ideas? I'm sure users will ask to generalize the scheme for other languages, where Automake operates differently now. I'm not yet sure whether that is a reason to worry or a good thing. ;-) 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. Should a package be an installable entity? At that point we should think about using a separate new _PRIMARY for it. 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. Setups like the following are not possible in theory? if WANT_FEATURE_IN_FOO foo_lo_SOURCES += baz.go else if WANT_FEATURE_IN_BAR bar_lo_SOURCES += baz.go endif endif Thanks, Ralf
Re: PATCH RFA: Add Go support
[ dropping libtool@ ] * Ian Lance Taylor wrote on Mon, Nov 01, 2010 at 09:48:03PM CET: Ralf Wildenhues ralf.wildenh...@gmx.de writes: We need a bit of new notation for this, and we need to teach automake about languages that shouldn't have renamed objects even in the presence of per-object flags. Hmmm, no, the objects can be renamed. The agreement between source level package name and file level package name is by convention only. Misunderstanding; sorry. What I meant was that automake shouldn't by itself rename object file names. It currently does that for example with setups like foo_SOURCES = foo.c bar_SOURCES = foo.c bar_CPPFLAGS = -Dbar 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. Should a package be an installable entity? At that point we should think about using a separate new _PRIMARY for it. A package can be installable by itself, sure. Would that then be in the form of an object, or would you make an archive out of it? 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. Setups like the following are not possible in theory? if WANT_FEATURE_IN_FOO foo_lo_SOURCES += baz.go else if WANT_FEATURE_IN_BAR bar_lo_SOURCES += baz.go endif endif Right, that is not possible, unless foo.lo and bar.lo define the same package, which would be very odd. Why? With system-dependent differences that doesn't seem too remote (the conditionals don't both have to be true on the same system). Generally, Automake users will eventually come up with some use case even for pretty remote cases ... Cheers, Ralf
Re: PATCH RFA: Add Go support
Ralf Wildenhues ralf.wildenh...@gmx.de writes: OK. So IIUC one example dependency graph would be something like this: ( sin.go cos.go exp.go ) - math.OBJEXT - libfem.so ( grid.go solver.go )- sub/pdesolve.OBJEXT ---^ where the sets of .go files are distinct, the sets of object files (packages) cannot be derived from their inputs (neither their names nor their contents?) but rather specified only in the makefile, and objects are subsumed in (static or shared) libraries or in programs as usual. OBJEXT may be o or obj (for w32) or lo (for libtool). That is essentially correct. The source file does include the name of the package. E.g., your example, each of sin.go, cos.go, and exp.go would start with package math. There is no necessary connection between the name used in the source file and the name of the object file. But it would certainly be conventional to use the same name for the package name and the object file name. We need a bit of new notation for this, and we need to teach automake about languages that shouldn't have renamed objects even in the presence of per-object flags. Hmmm, no, the objects can be renamed. The agreement between source level package name and file level package name is by convention only. 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. Should a package be an installable entity? At that point we should think about using a separate new _PRIMARY for it. A package can be installable by itself, sure. 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. Setups like the following are not possible in theory? if WANT_FEATURE_IN_FOO foo_lo_SOURCES += baz.go else if WANT_FEATURE_IN_BAR bar_lo_SOURCES += baz.go endif endif Right, that is not possible, unless foo.lo and bar.lo define the same package, which would be very odd. Ian
Re: PATCH RFA: Add Go support
Ralf Wildenhues ralf.wildenh...@gmx.de writes: [ dropping libtool@ ] * Ian Lance Taylor wrote on Mon, Nov 01, 2010 at 09:48:03PM CET: Ralf Wildenhues ralf.wildenh...@gmx.de writes: We need a bit of new notation for this, and we need to teach automake about languages that shouldn't have renamed objects even in the presence of per-object flags. Hmmm, no, the objects can be renamed. The agreement between source level package name and file level package name is by convention only. Misunderstanding; sorry. What I meant was that automake shouldn't by itself rename object file names. It currently does that for example with setups like foo_SOURCES = foo.c bar_SOURCES = foo.c bar_CPPFLAGS = -Dbar Ah, I see. Yes, it would not make sense to do this for Go. A package can be installable by itself, sure. Would that then be in the form of an object, or would you make an archive out of it? It could be either way. If there is only the one object, it might as well just be a .o file. 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. Setups like the following are not possible in theory? if WANT_FEATURE_IN_FOO foo_lo_SOURCES += baz.go else if WANT_FEATURE_IN_BAR bar_lo_SOURCES += baz.go endif endif Right, that is not possible, unless foo.lo and bar.lo define the same package, which would be very odd. Why? With system-dependent differences that doesn't seem too remote (the conditionals don't both have to be true on the same system). Generally, Automake users will eventually come up with some use case even for pretty remote cases ... It's normal to have a single package which had conditionally included source files. But what you are describing seems to be the case of the same source file going into two different packages. I don't know why that would ever be useful or interesting. But, yes, it could be done, if both of the two different packages used the same name at the source code level. Ian
