Go Build Frameworks

[Russel Winder]

Of all the non-SCons, non-Waf build frameworks listed at
http://go-lang.cat-v.org/dev-utils it seems that gobuild, gofr, godag,
goam, and go-gb are still active projects, the others appear to have
fallen by the wayside. Is there a clear favourite emerging in the race
to be the framework that takes over from Make for building Go projects,
or is it still very much an open charge?

Thanks.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Johann Höchtl]

In order to get an unbiased view, respondents should include the tools
they have already used.

I for one only have experience with go-gb which has never let me down
and works on any project layout I had. The author is responsive on
questions and/or suggestions and maintains the tool for the weekly
releases. For what I know the tool supports structuring your projects
as inteded by the go authors. I am not including features etc. here.

Johann

gobuild, gofr, godag, goam, go-gb are still active projects, the

others appear to have
> fallen by the wayside.

> < 1KViewDownload

[André Moraes]

Making your packages work with goinstall is a better approach.

goinstall is the common denominator for the Go environment and is
pretty easy to use.
It put some limitations on the layout that you can use on your program.

On the other hand, if you don't care about easy of installation on
other computers,
go-gb looks the better alternative so far.

--
André Moraes
http://andredevchannel.blogspot.com/

[John Asmuth]

On Wednesday, July 27, 2011 9:40:22 AM UTC-4, André Moraes wrote:

Making your packages work with goinstall is a better approach.

I try to make gb and goinstall work on the same set of assumptions, so that switching between the two is easy. gb lets you do a little more configuration if you want, but it's easy to just not use those features (as the package author), and they're absent by default.

goinstall is the common denominator for the Go environment and is
pretty easy to use.
It put some limitations on the layout that you can use on your program.

On the other hand, if you don't care about easy of installation on
other computers,
go-gb looks the better alternative so far.

"gb -M" will create a set of makefiles and a build script to let you distribute without a gb dependence :)

 

[Mark Summerfield]

On Wed, 27 Jul 2011 14:29:02 +0100
Russel Winder <rus...@russel.org.uk> wrote:
> Of all the non-SCons, non-Waf build frameworks listed at
> http://go-lang.cat-v.org/dev-utils it seems that gobuild, gofr, godag,
> goam, and go-gb are still active projects, the others appear to have
> fallen by the wayside. Is there a clear favourite emerging in the
> race to be the framework that takes over from Make for building Go
> projects, or is it still very much an open charge?
>
> Thanks.

I tried gobuild quite a while ago but didn't have much success.
(Probably my fault rather than gobuild's.)

I now use goinstall on Linux & Mac but it doesn't work on Windows, so
for Windows I use gb. Also, I use gb -c to clean up on Linux & Mac since
goinstall -clean doesn't seem to clean anything.

I believe that the gomake tool will be rereleased as a build tool that
doesn't depend on Make (and so might be cross-platform); but I don't
know when or if and how compatible it will be for projects built using
goinstall.

--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Advanced Qt Programming" - ISBN 0321635906
http://www.qtrac.eu/aqpbook.html

[Kyle Lemons]

Full disclosure: I am the author of gofr.

TL;DR: Use gb until goinstall/gotest/gomake are done, then try switching to them.

I have tried all of the build tools that were active before I released `gofr` and found them lacking in an area that was important to me at the time: relative imports.  I wanted a build tool that would allow a to import a/b without specifying absolute package paths, etc.  So, I made gofr.  At that point, there was very little standardization among package layouts, and I found this the most sensible based on a C/C++ background (this was around the time that goinstall was seeing some of its bigger steps out into the sunlight).  I implemented some things like testing support and cgo support as exercises in familiarizing myself with how everything interrelates, and because I like understanding how things work.  The gb project was started during a lull in my Go participation while I did a cross-country move and started a new job, and has done a much better job of tracking the community's collective ideas about proper project organization, and (from what I can tell) has been tracking the new changes to goinstall.  Because of this, the only maintenance I have done on gofr is to keep it relatively up-to-date with the current release, though I let cgo support fall off.  I personally hope that all of these build tools will eventually either deprecate themselves or change direction to become an addition to (the new) goinstall/gomake instead of a replacement for it.  As Andrew's changes to go/build and goinstall and the changes I suspect are coming to gomake and gotest come to fruition, I will be keeping my eyes peeled for an opportunity to redefine gofr's mission, but if they are able to fully define the space, I'll be happy to have my project replaced by standard go commands.

Cheers,

~K

[Jan Mercl]

I wonder what kind of programs people are routinely/on average writing when they are able not to use make. I just checked and about 1 in 4 of Go packages which were produced in our company do depend  on golex and/or goyacc to build, so 'make' (or any other equivalence of its ability to invoke such tools) is our only automated option...

[John Asmuth]

On the other hand, I have never written anything that depended on golex or goyacc. It really depends on the kind of stuff you do!

I wrote gb because I had a project with about 20 packages and 10 commands, and my clean-build script I had to make sure things built correctly took an irritatingly long amount of time (I'm a compulsive compiler, so waiting 10 seconds for all the commands to link was a pain).

All of them were simple enough so that the default makefile, with the correct file list, was sufficient.

[Kyle Lemons]

I wonder what kind of programs people are routinely/on average writing when they are able not to use make. I just checked and about 1 in 4 of Go packages which were produced in our company do depend  on golex and/or goyacc to build, so 'make' (or any other equivalence of its ability to invoke such tools) is our only automated option...

That is certainly an interesting point, and something which none of the build tools address.  It would be adding complexity and another "convention" and probably shouldn't be in the standard goinstall/gomake, but perhaps generated go files could start with something like:

//! Generated by `<command>` from <list of files>

It would be suitably human readable, but could also serve to enlighten a build tool about how to generate that go file.  In this way, you could version control the .go file so that standard installations of go can check out your project and build it, but anyone doing development (hopefully using the same build tool) would have a tool smart enough to do the dependency check and rebuild it.

~K

[Andrew Gerrand]

I believe that the gomake tool will be rereleased as a build tool that
doesn't depend on Make (and so might be cross-platform); but I don't
know when or if and how compatible it will be for projects built using
goinstall.

 The design decisions we made for goinstall will still hold for gomake.

Andrew

[brainman]

On Thursday, 28 July 2011 02:28:26 UTC+10, Mark wrote:

> I now use goinstall on Linux & Mac but it doesn't work on Windows, ...

I use goinstall on Windows with no problems. It uses mingw make by default, but if you specify -make=false flag, you won't even need mingw to use goinstall. If you file an issue http://code.google.com/p/go/issues/list, I'll ivestigate it. Thank you.

Alex

[Christopher Dunn]

Relative imports would be great, Kyle!

[Jan Mercl]

On Wednesday, July 27, 2011 6:28:26 PM UTC+2, Mark wrote:

I believe that the gomake tool will be rereleased as a build tool that
doesn't depend on Make (and so might be cross-platform);

AFAIK e.g. GNU Make is cross platform.

[Kyle Lemons]

On Wed, Jul 27, 2011 at 4:48 PM, Christopher Dunn <cdun...@gmail.com> wrote:

Relative imports would be great, Kyle!

gofr supports them, but they're not the idiomatic way to do things anymore, and I've become a convert.  You will have to use gofr to generate a build script or anyone who wants to compile your app would need gofr, which is not ideal.

~K

[Mateusz Czapliński]

The only problem is that Makefiles are rarely such.

/M.

[Jan Mercl]

On Friday, July 29, 2011 9:17:05 AM UTC+2, Mateusz Czapliński wrote:

On Jul 28, 11:16 am, Jan Mercl <jan....@nic.cz> wrote:
> AFAIK e.g. GNU Make is cross platform.

The only problem is that Makefiles are rarely such.

Sorry, I'm confused. Did you mean that Go Makefiles aren't GNU Make Makefiles or something else?

[John Asmuth]

He means that the a makefile often won't work on multiple platforms, except in the simplest and most complex cases.

[Jan Mercl]

On Friday, July 29, 2011 1:24:51 PM UTC+2, John Asmuth wrote:

He means that the a makefile often won't work on multiple platforms, except in the simplest and most complex cases.

Are there any examples for this found anywhere in the Go source tree (considering all the supported platforms)? I don't think so.

And outside the Go source tree? I don't know, haven't yet seen any such. Sure, it's always possible to write non portable things, Make Makefiles included ;-)

[John Asmuth]

On Friday, July 29, 2011 7:41:32 AM UTC-4, Jan Mercl wrote:

On Friday, July 29, 2011 1:24:51 PM UTC+2, John Asmuth wrote:

He means that the a makefile often won't work on multiple platforms, except in the simplest and most complex cases.

Are there any examples for this found anywhere in the Go source tree (considering all the supported platforms)? I don't think so.

Well, I don't imagine building runtime on windows would work with the existing makefile...

 

And outside the Go source tree? I don't know, haven't yet seen any such. Sure, it's always possible to write non portable things, Make Makefiles included ;-)

Absolutely there are - just think of all the libraries you need to link.

He's not referring to syntax - just that the build process is unique for every platform and that makefiles don't address that at all. 

[Jan Mercl]

On Friday, July 29, 2011 1:56:10 PM UTC+2, John Asmuth wrote:

Well, I don't imagine building runtime on windows would work with the existing makefile...

I believe you, but it surprises me. Unfortunately I can't even try it. Would I have a Windows box available, I wonder if the Makefile would finish the build with e.g. Cygwin. Or if it could after some changes.

 

And outside the Go source tree? I don't know, haven't yet seen any such. Sure, it's always possible to write non portable things, Make Makefiles included ;-)

Absolutely there are - just think of all the libraries you need to link.

That demands a Makefile to be written platform aware, it doesn't mean the Makefile is not/couldn't be cross platform (on supported platforms). Or if linking with a platform locked library is meant, then it's not a fault of Make that e.g. an already non cross platform app linking win32.dll (or whatever it's name) can't be easily/at all built on a POSIX system.

 

He's not referring to syntax - just that the build process is unique for every platform and that makefiles don't address that at all. 

So as the Build Frameworks do not address everything (cf. goyacc and any other tools like that).

Perhaps I'm an old school guy, but for me Make solves much more then Build Frameworks and it is pretty cross platform, I think. On average our existing Go Makefiles, excluding the boilerplate, are like 10-20 lines written once per package. Pretty low cost, IMO.

[Miek Gieben]

[ Quoting Jan Mercl at 05:51 on July 29 in "[go-nuts] Re: Go Build Frameworks"... ]

> So as the Build Frameworks do not address everything (cf. goyacc and any other
> tools like that).
>
> Perhaps I'm an old school guy, but for me Make solves much more then Build
> Frameworks and it is pretty cross platform, I think. On average our existing Go
> Makefiles, excluding the boilerplate, are like 10-20 lines written once per
> package. Pretty low cost, IMO.

+1

grtz,

--
Miek

[John Asmuth]

It's more than the zero lines required by goinstall, gb, gofr or gd.

And when your project has something more complicated, gb at least can run the makefile for you (and still do incremental building according to the import statements).

[Mateusz Czapliński]

On Jul 29, 2:51 pm, Jan Mercl <jan.me...@nic.cz> wrote:
> So as the Build Frameworks do not address everything (cf. goyacc and any
> other tools like that).
>
> Perhaps I'm an old school guy, but for me Make solves much more then Build
> Frameworks and it is pretty cross platform, I think. On average our existing
> Go Makefiles, excluding the boilerplate, are like 10-20 lines written once
> per package. Pretty low cost, IMO.

I do totally agree that Make is a much more universal tool than the
current Go "Build Frameworks", and the power it gives can often be
needed. I do also very much admire how The Go Team managed to make the
basic end-user Makefiles for Go so simple to write, use and read.

Unfortunately, among other problems, Makefiles are usually strongly
tied to the underlying OS (in Open-Source, often Linux, and the Go
runtime Makefiles are a pretty good example here). And it's too easy
to make them such, while too difficult to make them not-such.
Actually, too easy to make them WorksForMe tied to original creator's
box, and too difficult to make them work on collegue's one... I do
have much more issues with the current state of art in build systems
in general, but as much as I'd actually love to vent my frustrations,
I'll end at that, as I sure don't want to hijack this thread. That's
totally for a different discussion, on a different forum or
something...

/M.

PS. Thanks John for patiently explaining my one-liner in more
detail :)

[Henrik Johansson]

2011/7/29 Mateusz Czapliński <czap...@gmail.com>

Hi,

2¢

The makefiles for a typical Go project do not seem complex at all, simple in fact but i just tried go-gb the other day and its just so simple and it does automagic good things like collect the executables in a bin directory. These things may seem trivial but for me who is trying to introduce Go to a heavy long-time Java shop its a great boon. "You are building this thing with 'Make'??" is what i often hear and they don't mean it in a good way. I would prefer a by default zero conf build system like gb simply because it is easier and if extra stuff like generators of what not needs to be called it would be nice if i could declare it in Go syntax in a file somewhere (cmp w SBT/Scala). It also rhymes very nice with Go's philosophy to be simple and get lots done easily.

Rgrds,

Henrik

[Kyle Lemons]

Hi,

2¢

The makefiles for a typical Go project do not seem complex at all, simple in fact but i just tried go-gb the other day and its just so simple and it does automagic good things like collect the executables in a bin directory. These things may seem trivial but for me who is trying to introduce Go to a heavy long-time Java shop its a great boon. "You are building this thing with 'Make'??" is what i often hear and they don't mean it in a good way. I would prefer a by default zero conf build system like gb simply because it is easier and if extra stuff like generators of what not needs to be called it would be nice if i could declare it in Go syntax in a file somewhere (cmp w SBT/Scala). It also rhymes very nice with Go's philosophy to be simple and get lots done easily.

Rgrds,

Henrik

There are already canonical tools in the pipeline that allow zero-configuration building and installing of go projects.  Goinstall can already do this to a certain extent, a new gomake and gotest are good bets to follow.

~K

[John Meinel]

On Jul 29, 2011 9:42 AM, "Mateusz Czapliński" <czap...@gmail.com> wrote:
>
> On Jul 29, 2:51 pm, Jan Mercl <jan.me...@nic.cz> wrote:
> > So as the Build Frameworks do not address everything (cf. goyacc and any
> > other tools like that).
> >
> > Perhaps I'm an old school guy, but for me Make solves much more then Build
> > Frameworks and it is pretty cross platform, I think. On average our existing
> > Go Makefiles, excluding the boilerplate, are like 10-20 lines written once
> > per package. Pretty low cost, IMO.
>
> I do totally agree that Make is a much more universal tool than the
> current Go "Build Frameworks", and the power it gives can often be
> needed. I do also very much admire how The Go Team managed to make the
> basic end-user Makefiles for Go so simple to write, use and read.
>

As an example, I currently auto-generate a version.go file using $VCS command > version.go which is pretty easy to put into a Makefile and with a bit of temp indirection won't trigger a full rebuild either. How would something like that be done in the "goinstall" world?

John

[John Asmuth]

Goinstall has no provisions for doing this.

For gb, I have thought about having it look for a file "prebuild.gb", which would be executed if it exists (and then the normal build process would happen), but I don't know if it's worth it. If you've got something more complicated, perhaps a makefile is just the best option.

With your example, it seems most straight forward to generate a new version of version.go whenever you commit a change (perhaps though a script). Then when people check it out, they won't have to generate it.

[Paul Borman]

I think adding the prebuild.gb will only start you down the path to insanity (your own sanity, that is!).  The problem is as soon as you handle that one special case then someone will say, oh but with Make I generate a file at the end of my build which has the checksum of my sources.  Now you can add a postbuild.db.  But that isn't quite right, as it is an almost-postbuild.gb.  Then you end up with someone who wants to auto-generate foo.gb based on foo.txt:

    foo.gb:  foo.txt

        snazzy-cvt < foo.gb > foo.txt

Make is a really good tool.  In BSD/OS we used to use pmake and a set of os/site specific makefile fragments in a known location.  It worked quite well and the makefiles were as simple as, sometimes simpler than, the Go makefiles you see.  Make and printf, two of my favorite friends who are too often derided.

    -Paul

[David Roundy]

I'll just add that generating go code from go is also one of those cases that are very difficult to do portably with make, which makes it particularly appealing for a go build tool, especially as it is so easy to generate go code from go.

What about a convention where a file ending in .go.go is a main program that generates a go file in the same location without the second .go.  The limitation of this approach is that your code-generation programs can only have one file in their main package, and would live in the same location as the generated code. Also, it opens up an attack vector in that you'd have to execute the code, which could be interpreted as a danger if I may be installing untrusted code.  On the other hand make is as bad, and go install is almost as bad.

David

On Jul 30, 2011 4:15 PM, "John Asmuth" <jas...@gmail.com> wrote:

[Jan Mercl]

On Sunday, July 31, 2011 11:37:16 AM UTC+2, David Roundy wrote:

I'll just add that generating go code from go is also one of those cases that are very difficult to do portably with make, which makes it particularly appealing for a go build tool, especially as it is so easy to generate go code from go.

What exactly is meant by 'generating go code from go'? If that means generating Go source code using a tool written in Go then I see no portability issues in the common cases. I.e. cases like gofmt -r, goyacc and other existing Go parser/lexer generators, some hypothetical tool using the template packages etc.

What about a convention where a file ending in .go.go is a main program that generates a go file in the same location without the second .go.  The limitation of this approach is that your code-generation programs can only have one file in their main package, and would live in the same location as the generated code. Also, it opens up an attack vector in that you'd have to execute the code, which could be interpreted as a danger if I may be installing untrusted code.  On the other hand make is as bad, and go install is almost as bad.

Goinstall is a very good tool for zero hassle install of packages hosted externally. "make is bad" is an interesting opinion, but hardly an acceptable argument.

[John Asmuth]

This seems like a great idea.

+1 from me. If the discussion goes well, I'll add it to gb and people can fool around with it. I think I could figure out a makefile patch, too.

GOFILES = a.go

GOGOFILES = a.go.go

Then I could patch Go-OpenGL to do this and let "gb -R" build it, instead of having to manually run its makefile every time I update my go distribution ;)

[Jan Mercl]

I would like to vote -1 about the .go.go extension. It's probably in conflict with some existing tools/scripts. I have a concrete in-house issues: e.g. our metrics collecting script would begin to report wrong numbers, others are that both some tests and examples included with our lexing oriented packages would stop working with such files. Please keep anything *.go to be a valid Go source file (sans all the syntax and logic errors possibly included in them ;-)

[John Asmuth]

Would the changes to your metric collecting script be non-trivial?

I don't understand the comment about lexing oriented packages.

[Jan Mercl]

On Sunday, July 31, 2011 5:19:50 PM UTC+2, John Asmuth wrote:

Would the changes to your metric collecting script be non-trivial?

They would be very trivial. The problem is in the decision to break an unknown amount of existing external things (like our existing scripts/examples) or - version 2 - adopt a way, which doesn't break them, i.e. unknown N changes vs known one change.

 

I don't understand the comment about lexing oriented packages.

From the already published code e.g. this example will break on a box with .go.go files anywhere in $GOROOT/src:

https://github.com/cznic/golex/blob/master/example2.l#L280

I don't care if anyone wants/needs to use some Build Framework. I *do* care if that would mean breaking things for other people in no need to use Build Frameworks. And yes, I honestly consider the idea of establishing a .go.go extension as a poor one.

[David Roundy]

I think you must have misunderstood my suggestion. A .go.go file *would* be a valid go program, which when compiled would yield an executable whose output is also valid go source code. The only incompatibility I can see would be with tools that assume that all the go code in a single directory must be for a single package, or that all the go files whose package is main and are in a single directory must be for the same executable. But I'd call any script that makes these assumptions broken.

David

[David Roundy]

On Jul 31, 2011 4:44 PM, "Jan Mercl" <jan....@nic.cz> wrote:
>> I don't understand the comment about lexing oriented packages.
>
>
> From the already published code e.g. this example will break on a box with .go.go files anywhere in $GOROOT/src:
> https://github.com/cznic/golex/blob/master/example2.l#L280

I don't see anything there that would break if .go.go files were used, since they would be valid go files.

David

[David Symonds]

On Tue, Aug 2, 2011 at 8:02 PM, David Roundy <daver...@gmail.com> wrote:

> The only incompatibility I can see would be with tools that assume that all
> the go code in a single directory must be for a single package, or that all
> the go files whose package is main and are in a single directory must be for
> the same executable. But I'd call any script that makes these assumptions
> broken.

You've just described a principal assumption of the build system for
the Go tree, and the majority of third party packages. It's also an
assumption that goinstall (and related tools) is based on, and will
continue to be based on in the future.

Dave.

[John Asmuth]

Not true. The core go tree has, goinstall and gb all allow a package to have, source files with package main mixed in with files with package whatever-the-package-is. goinstall and gb ignore these files. I had to build this feature into gb to allow it to build the core packages - I forget where it came up.

The only thing that would break is cmd targets - goinstall/gb would try to compile the .go.go file in with the rest. Some code would have to be written to change this.

 

[John Asmuth]

On Sunday, July 31, 2011 11:44:11 AM UTC-4, Jan Mercl wrote:

From the already published code e.g. this example will break on a box with .go.go files anywhere in $GOROOT/src:

https://github.com/cznic/golex/blob/master/example2.l#L280

Also an easy change... 

 

I don't care if anyone wants/needs to use some Build Framework. I *do* care if that would mean breaking things for other people in no need to use Build Frameworks.

On a basic level, I consider the "it would break stuff" argument insufficient. Changes to the language break stuff every month. It doesn't change anything fundamental, and any fix would be easy.

And yes, I honestly consider the idea of establishing a .go.go extension as a poor one.

Why? Beyond the fact that it would require fixing some existing tools?

One reason I can think of is that this only deals with one possible prebuild step. A change from zero prebuild operations to one prebuild operation is significant, and would make the argument against adding additional prebuild steps of various sorts weaker. We might end up with 90 special file types that we all have to deal with.

I'd much rather agree on a standard that can do any kind of prebuilding. A special name for a shell script, perhaps.

Or, alternatively, no change.

[David Roundy]

On Aug 2, 2011 12:37 PM, "John Asmuth" <jas...@gmail.com> wrote:
> One reason I can think of is that this only deals with one possible prebuild step. A change from zero prebuild operations to one prebuild operation is significant, and would make the argument against adding additional prebuild steps of various sorts weaker. We might end up with 90 special file types that we all have to deal with.
>
> I'd much rather agree on a standard that can do any kind of prebuilding. A special name for a shell script, perhaps.
>
> Or, alternatively, no change.

I think using shell scripts would be a terrible idea: it's notoriously hard to write a portable shell script, and that's leaving out the possibility of building on windows. Much nicer to use go scripts if anything. It's true that the .go.go idea doesn't address all possible prebuild possibilities, but I'm not sure that's a problem. We aren't going to find a flexible approach that treats dependencies that is simpler than make and the beauty of gb, go install are in their convention-over-configuration approach.  Any convention is going to imply some degree of limitation.

I suppose a good idea would be to consider use cases that aren't currently handled by gb or goinstall.  One is to handle generated code code a la gotgo, another would be what I worked on with goadmin, which was a system for creating programs based on the state of a computer (e.g. to replicate the set of Unix users on the build system). Neither are compelling stories, nor are they actively maintained.  But if you've also got situations where you want to generate go code then maybe it's not so rare...

David

[⚛]

On Jul 27, 3:29 pm, Russel Winder <rus...@russel.org.uk> wrote:
> Of all the non-SCons, non-Waf build frameworks listed athttp://go-lang.cat-v.org/dev-utilsit seems that gobuild, gofr, godag,
> goam, and go-gb are still active projects, the others appear to have
> fallen by the wayside.  Is there a clear favourite emerging in the race
> to be the framework that takes over from Make for building Go projects,
> or is it still very much an open charge?

In my opinion, it is a matter of investment - the author(s) has to
invest more time into the development of the build tool. The tool with
the biggest time investment wins the race (unless the tool's
architecture is wrong, of course).

I am the author of "goam". It uses Go code in the configuration files.
I do not see many issues reported at https://github.com/0xe2-0x9a-0x9b/goam/issues
which probably indicates that nobody is using the tool.

> Thanks.
>
> --
> Russel.
> =========================================================================== ==
> Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: rus...@russel.org.uk
> London SW11 1EN, UK   w:www.russel.org.uk skype: russel_winder
>
>  signature.asc
> < 1KViewDownload

[uki]

Why not just add a, per directory Makefile that produces .go file, and
make goinstall use it?

Łukasz Gruner

2011/8/2 ⚛ <0xe2.0x...@gmail.com>:

[⚛]

I am not sure I fully understand what you are referring to. Is this is
a question about configuration files in goam?

On Aug 2, 7:43 pm, uki <uka...@gmail.com> wrote:
> Why not just add a, per directory Makefile that produces .go file, and
> make goinstall use it?
>
> Łukasz Gruner
>

> 2011/8/2 ⚛ <0xe2.0x9a.0...@gmail.com>:

>
>
>
>
>
>
>
> > On Jul 27, 3:29 pm, Russel Winder <rus...@russel.org.uk> wrote:

> >> Of all the non-SCons, non-Waf build frameworks listed athttp://go-lang.cat-v.org/dev-utilsitseems that gobuild, gofr, godag,

> >> goam, and go-gb are still active projects, the others appear to have
> >> fallen by the wayside.  Is there a clear favourite emerging in the race
> >> to be the framework that takes over from Make for building Go projects,
> >> or is it still very much an open charge?
>
> > In my opinion, it is a matter of investment - the author(s) has to
> > invest more time into the development of the build tool. The tool with
> > the biggest time investment wins the race (unless the tool's
> > architecture is wrong, of course).
>
> > I am the author of "goam". It uses Go code in the configuration files.

> > I do not see many issues reported athttps://github.com/0xe2-0x9a-0x9b/goam/issues

[John Asmuth]

On Tuesday, August 2, 2011 2:41:12 PM UTC-4, ⚛ wrote:

I am not sure I fully understand what you are referring to. Is this is
a question about configuration files in goam?

 

FWIW It's not just you. 

[David Roundy]

It's hard to write portable makefiles.

David

[Andrew Gerrand]

On Tuesday, August 2, 2011 10:43:16 AM UTC-7, ukaszg wrote:

Why not just add a, per directory Makefile that produces .go file, and
make goinstall use it?

Two of the design goals of goinstall are to:

  - not depend on make, and

  - not become make.

Andrew

[Mark Summerfield]

On Wed, 27 Jul 2011 16:45:39 -0700 (PDT)
brainman <alex.b...@gmail.com> wrote:
> On Thursday, 28 July 2011 02:28:26 UTC+10, Mark wrote:
>
> > I now use goinstall on Linux & Mac but it doesn't work on
> > Windows, ...
>
> I use goinstall on Windows with no problems. It uses mingw make by
> default, but if you specify -make=false flag, you won't even need
> mingw to use goinstall. If you file an issue
> http://code.google.com/p/go/issues/list, I'll ivestigate it. Thank
> you.
>
> Alex

Hi, I finally tried it again but without success:
http://code.google.com/p/go/issues/detail?id=2137

--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Rapid GUI Programming with Python and Qt" - ISBN 0132354187
http://www.qtrac.eu/pyqtbook.html

[John Asmuth]

When I try to use goinstall on windows, it just tells me "invalid file descriptor" right off the bat.

[Mark Summerfield]

I'm also having problems with goinstall on Windows:
http://code.google.com/p/go/issues/detail?id=2137

--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy

"Programming in Go" - ISBN 0321774639
http://www.qtrac.eu/gobook.html

[peterGo]

Mark,

> Hi, I finally tried it again but without success:http://code.google.com/p/go/issues/detail?id=2137

Follow the instructions for the goinstall command.
http://code.google.com/p/go/issues/detail?id=2137

Peter

On Aug 8, 5:31 am, Mark Summerfield <m...@qtrac.eu> wrote:
> On Wed, 27 Jul 2011 16:45:39 -0700 (PDT)
>

[peterGo]

Mark,

> I'm also having problems with goinstall on Windows:http://code.google.com/p/go/issues/detail?id=2137

Follow the instructions for the goinstall command.
http://code.google.com/p/go/issues/detail?id=2137

Peter

On Aug 8, 7:36 am, Mark Summerfield <l...@qtrac.plus.com> wrote:
> On Mon, 8 Aug 2011 04:15:02 -0700 (PDT)
>

[brainman]

See http://code.google.com/p/go/issues/detail?id=1826.

Some later versions of Windows (Windows 7) disallow executable files to have particular names. goinstall.exe happens to be one of those restricted names.

You could rename goinstall.exe to something more suitable for your OS. Alternatively you could disable appropriate OS service that restrict you running the program. I also have heard that you could include a "manifest" file as part of your goinstall.exe to overcome the protection. Ultimately, I think, goinstall.exe will be renamed, so this problem will just go away.

Alex

[John Asmuth]

They...reserved... goinstall?

[Krzysztof Kowalczyk]

On Mon, Aug 8, 2011 at 6:55 PM, John Asmuth <jas...@gmail.com> wrote:
> They...reserved... goinstall?

It's a bit more complicated (and reasonable) than that.

Unsurprisingly, many (buggy) XP programs do not work under Vista or
later because they were not written correctly. Microsoft tries to
protect Vista users from those programs by not running them. They have
a a heuristic that flags pre-Vista programs with "setup" or "install"
in their name as most likely being incorrect and refuses to run them,
probably based on hard, imperical data.

This doesn't mean that Vista refuses to run all programs that have a
"setup" or "install" in their names.

With XP Microsoft introduced a manifest file which is an XML file that
can be embedded inside .exe as a resource (or provided as a separate
file alongside the .exe e.g. foo.exe.manifest is an XML manifest for
foo.exe).

One of the things that can be described in the manifest file is an OS
compatibilty level where a programmer can state "I promise this
program works correctly under Vista" which will turn off the
filename-based compatiblity heuristic.

Basically Vista (and 7) doesn't trust pre-Vista executables (and
especially those with "isntall" or "setup" in their name) and it's
programmer's job to mark the executables explicitly as Vista (and 7)
compatible.

In the context of goinstall.exe (and all other executables that are
part of Go installation), Windows build should embed the right XML
manifest which will tell Windows that it's ok to run goinstall.exe
(and others) on Vista and 7.

The magic incantation is:
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--This Id value indicates the application supports Windows Vista
functionality -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--This Id value indicates the application supports Windows 7
functionality-->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
</application>
</compatibility>

(see http://code.google.com/p/sumatrapdf/source/browse/trunk/src/installer/Installer.exe.manifest
for a full manifest file that I use for an installer for my app)

This can also be done by a user via UI
(http://www.howtogeek.com/howto/windows-vista/using-windows-vista-compatibility-mode/)
but clearly that's not a scalable solution.

-- kjk