compile fails to resolve main package dependencies

[quan-xie]

compile fails to resolve main package dependencies

[GoogleCodeExporter]

I'm not quite sure what the right thing to do here is.  When there's a file in 
the top-level cmd folder, e.g. cmd1.go, the builder assumes that it's a 
stand-alone file that should be compiled into cmd1.exe.  If you create a 
sub-folder of cmd called "subf" and put the files in there, the builder will 
compile them together to make an executable called subf.exe.  This would solve 
the problem of referencing fromCmd1 and fromCmd2, but causes an error because 
of the redefinition of func main.

For reference executing 8g cmd1.go cmd2.go also results in an error: 
"cmd2.go:3: main redeclared in this block previous declaration at cmd1.go:3"

The other way to handle it, of course is to put fromCmd1 and fromCmd2 in 
packages under src/pkg.

Original comment by [email protected] on 3 Nov 2010 at 1:41

[GoogleCodeExporter]

yes, you are right. I did not compile by hand the sample I gave you. Of course 
it would give an error about the redefinition of main. However I think it was 
my example that wrongly did this redefinition. The gocode has only one main 
function in the main package, as expected. 

so building with:

8g cmd1.go cmd2.go
8g cmd2.go cmd1.go
would generate .8 files for both cmd1 and cmd2

then the linker would be called only for the one that actually has main. They 
can still refer each other in other forms (through other functions)

Your suggestion is actually what I did to compile gocode. I moved all code from 
the main package to a new package in the pkg, then created a cmd that actually 
calls the main() function from gocode.go which is now well packed in it's 
package.
But this is not something we can ask of developers. If they decide to use 
multiple files at the main package level, I think they should be able to do it.

Original comment by [email protected] on 3 Nov 2010 at 2:05

[GoogleCodeExporter]

Right, I had forgotten you were compiling gocode.  You can get it to work by 
putting all the top-level source files into a subfolder of cmd called "gocode". 
 Then put the "goconfig" files into src/pkg/configfile.  Then the only problem 
is the 'import cfg "./configfile"' in config.go.  If you change that to "import 
cfg "configfile"' it works fine.

So once again, it comes down to how to handle an import prefixed with "./"  Is 
the answer simply to look for local packages in the pkg folder?  If so, what is 
the best way to get the go toolchain to do that?

Original comment by [email protected] on 3 Nov 2010 at 7:36

[GoogleCodeExporter]

I did not expect to have a folder in cmd. This works great :)

I think we do need to handle the ./ packages somehow. People seem to use it. I 
wonder how is usually handled in linux. Is the make build doing something to 
change the ./ notation to a global one? or the packaging works file with ./ ?

I've tried to find some docs about gopack but the only thing I found is a link 
to a different tool in Plan9 which has different sets of parameters now.

Original comment by [email protected] on 6 Nov 2010 at 6:52

[GoogleCodeExporter]

Original comment by [email protected] on 10 Jun 2012 at 10:46

• Changed state: Fixed