3 ms·

You just want this feature to be more than it is. It's a small, simple thing. Don't overthink it. If you need a more elaborate build system, use one.

by enneff 12y ago

codemac 12y ago
> If you need a more elaborate build system, use one. I thought I was: https://golang.org/doc/articles/go_command.html https://golang.org/doc/articles/go_command.html > An explicit goal for Go from the beginning was to be able to build Go code using only the information found in the source itself, not needing to write a makefile or one of the many modern replacements for makefiles. If Go needed a configuration file to explain how to build your program, then Go would have failed.
- enneff 12y ago
  I said "use a more elaborate build system." That means, "more elaborate than the Go tool." So, no, you're not.
wtetzner 12y ago
It's a small, simple thing, but I still don't see what value it adds to just using a script.
- NateDad 12y ago
  It's cross platform compatible with no other dependencies, and the instructions live close to the code that are affected by them.
  - TheDong 12y ago
    "cross platform compatible with no other dependencies". No, not at all. Not even close. Your go generate comment takes the form of //go:generate someCommand arg1 arg2 That's as far from cross-platform as possible. For example, their "yacc" example will not run on a platform without yacc. Any command you put there will have to be present on each platform and any command you put there is a dependency. Worse yet, it's a dependency that you can't explicitly declare and manage. You can't say "runtime dependencies: github.com/tools/godep, generate dependencies: yacc". This is a terrible mess if you want to write a cross-platform generator and it's an even bigger mess if your generator isn't something present on every platform already because otherwise generate will just fail with "command not found".
    - 4ad 12y ago
      Nitpick: Go's yacc is part of the standard Go distribution, every Go installation has it. But it doesn't matter, go generate can indeed use programs a user might not have. But you know what, that doesn't matter either, it's true for shell scripts and it's true for makefiles as well. Go generate changes nothing in that respect, however, it does improve portability significantly in other ways. For example, in the Go tree we replaced shell scripts with go generate and perl scripts with go code called by go generate. This is important because Windows and Plan 9 don't have bourne shells, Plan 9 doesn't have perl at all and in Windows perl has to be installed. Note that there are no makefiles, which don't exist natively on Windows and Plan 9 either.

You just want this feature to be more than it is. It's a small, simple thing. Don't overthink it. If you need a more elaborate build system, use one.

by enneff 12y ago

You just want this feature to be more than it is. It's a small, simple thing. Don't overthink it. If you need a more elaborate build system, use one.

codemac 12y ago

> If you need a more elaborate build system, use one. I thought I was: https://golang.org/doc/articles/go_command.html https://golang.org/doc/articles/go_command.html > An explicit goal for Go from the beginning was to be able to build Go code using only the information found in the source itself, not needing to write a makefile or one of the many modern replacements for makefiles. If Go needed a configuration file to explain how to build your program, then Go would have failed.

enneff 12y ago
I said "use a more elaborate build system." That means, "more elaborate than the Go tool." So, no, you're not.

wtetzner 12y ago

It's a small, simple thing, but I still don't see what value it adds to just using a script.

NateDad 12y ago
It's cross platform compatible with no other dependencies, and the instructions live close to the code that are affected by them.
- TheDong 12y ago
  "cross platform compatible with no other dependencies". No, not at all. Not even close. Your go generate comment takes the form of //go:generate someCommand arg1 arg2 That's as far from cross-platform as possible. For example, their "yacc" example will not run on a platform without yacc. Any command you put there will have to be present on each platform and any command you put there is a dependency. Worse yet, it's a dependency that you can't explicitly declare and manage. You can't say "runtime dependencies: github.com/tools/godep, generate dependencies: yacc". This is a terrible mess if you want to write a cross-platform generator and it's an even bigger mess if your generator isn't something present on every platform already because otherwise generate will just fail with "command not found".
  - 4ad 12y ago
    Nitpick: Go's yacc is part of the standard Go distribution, every Go installation has it. But it doesn't matter, go generate can indeed use programs a user might not have. But you know what, that doesn't matter either, it's true for shell scripts and it's true for makefiles as well. Go generate changes nothing in that respect, however, it does improve portability significantly in other ways. For example, in the Go tree we replaced shell scripts with go generate and perl scripts with go code called by go generate. This is important because Windows and Plan 9 don't have bourne shells, Plan 9 doesn't have perl at all and in Windows perl has to be installed. Note that there are no makefiles, which don't exist natively on Windows and Plan 9 either.