Add developer toolkit

[alexg9010]

This is supposed to be a helper script that aggregates commonly used commands.

[alexg9010]

@rekado please feel free to mention any complications that you potentially see with this script.
And let me know if I should adjust the PR in any way.

[rekado]

This has no effect. Exporting environment variables only affects the current shell. In the case of a script that shell is the one executing the script, not the shell in which the script is invoked.

(Only source can affect the current shell session.)

[alexg9010]

@rekado
right now the script can only be executed if we are in the main git directory.
Is this a legal assumption or should make sure it is possible to run it from everywhere?

[rekado]

@rekado
right now the script can only be executed if we are in the main git directory.
Is this a legal assumption or should make sure it is possible to run it from everywhere?

It's a bit shaky. The script will always be located in a sub-directory, because that's how we include this repository as a submodule. So out of the box it won't work, which is a bit sad.

[alexg9010]

The way I handled it now is to create a symbolic link to the main directory and then run it from there.

A more powerful solution would probably be to include it in the configure / make process and record the absolute path of the base directory. Then you could run it independently of the working directory.

[rekado]

The problem with including it in configure/make is that neither of these is available before you run ./bootstrap.sh, so you won't be able to cover the full set of features.

GNU packages often include an extra Makefile for maintenance tasks; that's named GNUmakefile and is preferred by GNU make in the presence of both Makefile and GNUmakefile. GNUmakefile includes Makefile when it exists, so it will always do the right thing. The effect is that you can always run make, even before bootstrapping the build system, and you can have a whole bunch of targets that are only of interest to maintainers.

You can see this in action in the GWL repository. The maintenance targets there only really make sense for GNU packages, though. (E.g. to create a release announcement message, to upload the release to GNU servers, to generate a NEWS file, etc.)