helper compiled to hardwired name

[Russel Winder]

When using this tool, it generates a compiled scons-go-helper. For someone working with a single architecture the fact that this platform specific file has a hardwired name is not a problem. However in the case where a single project source tree is shared amongst a number of different architectures this presents a real problem. Either the file name needs to have a platform specific name so that mutliple versions can coexist in the same directory, or use needs to be made of independent, platform-specific diorectories in which to keep compiled material such as this.

[Ross Light (quartz25)]

You're absolutely right. Should hopefully be able to get this fixed within a week.

[Ross Light (quartz25)]

I've patched this in trunk r28. The helper needs to run natively (for dependencies and such), but I added a new GoTarget method to environments that use the tools that sets up environments for cross-compiling.

[Russel Winder (russel)]

I pulled and tried, but now I cannot compile anything :-( I think that whereas the tool just used to issue the command name on the assumption that the user had the appropriate tools in their path, now the tool assuming that the executables are in $GOHOME/bin which is not correct, the exectuables are in a place of the users choosing. In my case $GOHOME/bin_<platform-discriminator>, so that I can have multiple platform support in the same GOHOME tree.

I guess I should branch the branch, make edits and push to a branch on Launchpad to create a pull request?

[Ross Light (quartz25)]

Yeah, you're right. It's a one-line fix that I completely messed up. trunk r29 should fix it. (SCons doesn't handle external environment variables very well.)

[Russel Winder (russel)]

OK, back in action again :-)

I wonder though if the default name of the executable should be platform dependent. Although the capabuility of supporting multiple platforms in a single filestore is there, the onus is on the SConscript writer to write it. This replicates the code currently in the Go tools: the SConscript writer is currently required to use the platform package to determine what parameters to give the builder in the Go tool. Where weird processing is going on this is fine, but for the normal case isn't it easier jhust to make the executable name depend on teh platform and so remove the need for most SConscript writers to even have to think about the problem?

[Ross Light (quartz25)]

The goal with this project is to give the minimal tools necessary to conveniently build a Go project out-of-the-box. Also, one of the reasons I like SCons is that even though it simplifies the process of creating build scripts, it is also very flexible to handle a great deal of workflows. I understand cross-compiling may be a common problem to be solved, it's one problem where I don't want to shove one workflow down the SConstruct writer's throat.

I can see why it would be convenient for you, but the way I would handle it (if I needed to cross-compile a project) would be to have each of the builds take place in a separate variant directory, and then at the very end copy the specific binaries into a bin directory. Maybe that's not what works for your project, so I wouldn't want to impose that upon you. The effort to describe this in the SConstruct would be minimal, and could even be configured by a build variable, if set up properly.

For the most part, I think most people want to use Go projects on their host architecture, so I'm leaving the default that way, and that means you can still have a one-line SConstruct that builds a functioning Go program in the way someone familiar with SCons would expect. I'm proud of that.

In short, I am keeping the cross-compiling support the way I have implemented it.

P.S. For the record, the one-liner is:
Environment(TOOLS=['default', 'go']).GoProgram('program', 'main.go')

[Russel Winder (russel)]

I understand the goal, though I would go for:

Environment ( tools = [ 'go' ] ).GoProgram ( 'main.go' )

and not have all the C, C++, Fortran, LaTeX, etc., etc. tools initialized when they are not needed, and infer the final executable name from the source or first item in the list of sources -- as C, C++, etc. do.

I think though we are debating at slight cross purposes. I am not trying to cross-compile, I have a number of machines with there being 5 different architectures, all sharing the same filestore. Thus the filestore in question is seen by each machine as its own for its host architecture. SCons has a mechanism for dealing with this in association with variant build directories.

Natural idioms indicate that the SConstruct is where the decisions on architecture and variant directory are taken. So for example with a "Hello World" project with the source in the subdirectory src, the SConstruct will look something like:

import platform
osName , _ , _ , _ , architectureName , _ = platform.uname ( )
discriminator = osName + '-' + architectureName
buildDirectory = 'build-' + discriminator
SConsignFile ( '.sconsign-' + discriminator + '.dblite' )
environment = Environment ( tools = [ 'go' ] )
#environment.GoTarget ( osName , architectureName )
Export ( 'environment' )
SConscript ( 'src/SConscript' , variant_dir = buildDirectory , duplicate = 0 )
Clean ( '.' , [ buildDirectory ] )

with the src/SConscript being something like:

Import ( 'environment' )
executable = environment.GoProgram ( 'helloWorld' , 'helloWorld.go' )
Return ( 'executable' )

So the issue is that the Go tool builds the helper not in the variant directory, which perhaps it shouldn't anyway, nor is the tool connected into SConsignFile infrastructure, nor is the file named in a platform dependent way. OK so I should use GoTarget, fair enough. But, and this is what I was trying to get at, in order to use GoTarget, I have to make explicit in the SConstruct the mapping from Python names of architectures to Go names, which means every user has to work this out for themselves. I think the Go SCons tool should obviate this by allowing GoTarget to work in terms of either Python names or Go names, with the tool sorting out the mapping to Go names if that proves necessary.

So I think in the above I should be able to uncomment the line:

environment.GoTarget ( osName , architectureName )

in teh above, but sadly doing this causes:

ValueError: Unrecognized platform: Linux, x86_64:
  File "/home/users/russel/Progs/OddsByLanguage/Go/HelloWorld/SConstruct", line 10:
    environment.GoTarget ( osName , architectureName )
  File "/home/Checkouts/Mercurial/SCons/bootstrap/src/engine/SCons/Environment.py", line 222:
    return self.method(*nargs, **kwargs)
  File "/home/users/russel/.scons/site_scons/site_tools/go/go.py", line 339:
    config = _get_platform_info(env, goos, goarch)
  File "/home/users/russel/.scons/site_scons/site_tools/go/go.py", line 81:
    raise ValueError("Unrecognized platform: %s, %s" % (goos, goarch))

[Ross Light (quartz25)]

I think the solution here (which also solves your other bug report) is that the "on-demand" helper build isn't supposed to be a permanent fix. If you make each machine have its own copy of scons-go-helper somewhere in the PATH (by running build-helper.sh), then the plugin will pick up on it and use it.

Instead of mixing Python platform with Go's, then just use Go's natively (I'm already doing the check for you :D), i.e.:

SConscript('src/SConscript', variant_dir='build-%s-%s' % (environment['ENV']['GOOS'], environment['ENV']['GOARCH']), duplicate=0)

[Russel Winder (russel)]

Oh all right ;-)

I guess this also helps if using GoSCons?