Currently, one can get the basic information from autogen itself by running it without any arguments or with the -h flag, but it would also be useful to be able to run man autogen to get all the information.

Note: it might conflict with, e.g., https://www.gnu.org/software/autogen/manual/autogen.html if we were to publish to the standard man page location with the name autogen, so we may need to choose a different name, or hold off on this for now.

The latest automated test failed as follows:

$ brew update
$ brew tap bazelbuild/tap
$ brew tap-pin bazelbuild/tap
Error: Calling brew tap-pin user/tap is disabled! Use fully-scoped user/tap/formula naming instead.
The command "brew tap-pin bazelbuild/tap" failed and exited with 1 during .

We need to update the macOS command for installing Bazel to take this recent change into account, as this used to work previously.

Looks like instead of the current set of commands:

$ brew tap bazelbuild/tap
$ brew tap-pin bazelbuild/tap
$ brew install bazel

we can simply run:

$ brew tap bazelbuild/tap
$ brew install bazelbuild/tap/bazel

When adding license header to python code, some code might have a runline (she-bang). Right now I run with --no-runline and it would be nice if the autogen tool could check if a runline exists and if insert the license below.

Offline feedback from a user:

Separating the license header from the "// TODO general file description" comment with a blank line would allow IDEs to collapse just the license boilerplate, yet show the actually useful general description comment. Right now that blank line starts with a comment separator, which causes IDEs to fold the TODO line too.

This would be a simple change, but will be backwards-incompatible, which we need to carefully consider, if folks are currently relying on this aspect of functionality.

One option is making a release immediately prior to this change, and annotate the change in behavior with the following release.

IPython notebook is a popular tool for machine learning developer/researcher. Would be great to add support for this.

Thanks,

It would be nice to have a utility that would run over a given set of files and output whether or not each of them have a valid header comment with a license in it.

This could be used in presubmit checks to ensure that no new files are added without such a license.

It could also be run from a unit test.

Caveats:

• need to handle years in the past
• need to handle whitespace changes, e.g., new lines or indentation changes
• need to handle minor changes around the license, such as flags to the #!/... line
• [maybe] avoid handling reflowed text, as that's a difficult problem

For an example, see Java Checkstyle.

When processing python test files the tool inserts extra code for python test files and python source files

#!/usr/bin/python

<license here>

import unittest


class FooTest(unittest.TestCase):

    def setUp(self):
        pass
    def tearDown(self):
        pass
    def testBar(self):
        pass


if __name__ == '__main__':
    unittest.main()

This is IMHO an example where the tool tries to do too much. If we are using this tool to insert license it should limit itself to just that and not try to do anything else. In our work we had to do python test files manually because of this

When using "-i" option on a file having an existing Unicode BOM, the BOM appears to be left it place. autogen should insert the new text following the BOM.

Example diff after applying "autogen -i" follows. The string <U+FEFF> shows BOM location.

@@ -1,3 +1,17 @@
+// Copyright 2017 Google Inc.
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+//      http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
 <U+FEFF>using UnityEngine;
 using UnityEngine.Rendering;
 using System.Collections;

We have existing feature requests (see issue #23 and issue #46) which require non-trivial implementation changes. Adding support for configuration may well require embedding inline Python code into the autogen shell script. Implementing UTF-8 BOM support is even more complex.

It is time to rewrite Autogen in an actual programming language rather than keep extending a shell script to handle more functionality. The current proposal on the table is Python, because it will not require compilation and will thus be easy to use in the same way that the shell script is, by referencing license boilerplate in relative directories, without running any additional commands.

For reference, see the Google shell style guide:

Shell should only be used for small utilities or simple wrapper scripts.

While shell scripting isn't a development language, it is used for writing various utility scripts throughout Google. This style guide is more a recognition of its use rather than a suggestion that it be used for widespread deployment.

Some guidelines:

• [...]
• If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date.

Bug:

• Start with foo.sh file checked into git with permissions 0755
• Run autogen.sh -i [...] foo.sh
• Issue: permissions changed to 0644

Expected behavior:

• Permissions are unaffected by addition of copyright comment to file

Currently, autogen.sh has the .sh extension as it is a shell script. In the future, we may want to rewrite it in a more powerful language, whether a scripting one such as Python or Ruby, or a compiled language such as Go.

In that case, everyone will have to update all of their pointers, and we will have to update all of our editor integrations, such as the one described in issue #13.

To avoid breaking existing users who upgrade in the short-term, we can implement this as follows:

• move the content of autogen.sh to autogen
• keep autogen.sh around for backwards-compatibility, simply as a wrapper for autogen

The find example on the README fails with BUILD files. It reports the language is not recognized. Perhaps the filename check in the main script should allow a */BUILD instead of just BUILD?

We should provide a separate, self-contained repo with Vim configuration files for easy integration with tools such as Pathogen, NeoBundle, Vundle, Plug, VAM, etc.

For an example of how easy this should be, see the installation instructions for vim-airline.

Running eslint produces the spaced-comment error:

Expected space or tab after '//' in comment spaced-comment

Here's the linting rule.

One workaround would be to change that rule to allow for a / exception:

"spaced-comment": ["error", "always", { "markers": ["/"] }]

Build DEB, RPM, and other packages for easy installation and upgrades, and to make the tool accessible to more users. Add to distributions as a standard package.

Note: this might conflict with other packages, e.g., https://packages.debian.org/wheezy/autogen so we may need to choose a different name, or hold off on this for now.

It would be nice to have a utility to bulk-update all files of a particular type or language and insert a comment at the top of the file.

Proposed feature evolution:

• v1: prepend given license to all files that match a filter or just in a list
• v2: detect whether or not a license header already exists and avoid modifying that file

"To add a few file type or feature"

Hello, firstly, thanks for providing this tool - it's a great little time saver! I have a slightly annoying request, though: would you consider changing the name to something that doesn't clash with GNU AutoGen?

One problem with the current name is that it's very tempting to sudo apt-get install autogen which installs the 22-year-old GNU AutoGen tool rather than your package. I've made this mistake myself and wasted some time puzzling over why none of the example autogen invocations from your docs worked. I know at least a couple of colleagues who've made the exact same mistake, so it can't just be me!

If you're not willing to change the name, can I suggest adding a note to the README warning users about this?

It doesn't seem to be supported yet.

.bat comment starts with 'rem '

Thanks,

Motivation

It's easy to run autogen as a one-off tool with the right flags to generate just the right license + comment header for a new file. However, a particular repository may want to choose standard defaults that all files should follow such that it's trivial to just run autogen foo.py and get just the right format for the header: the right copyright owner, license, and other settings.

In the future, we may add further customizations, e.g., ability to modify the #! line to set different set of default flags, or to run #!/usr/bin/env <binary> rather than simply #!/usr/bin/<binary>, or to avoid automatic C/C++ header guards, or to compute them differently, or to avoid automatic Python boiler plate, etc.

Proposal

Define and implement a config file format, say .autogen.yml that could be stored directly in a repository, version-controlled, that autogen would read and populate its flags' default values from that file, thus enabling:

• running autogen without any command line flags could still be meaningful for the repo
• overriding any of the repo-default flags is trivial on a per-run basis

This will also enable us to have a single distributable integration with a given editor, since we can just run autogen -s <file> and all the correct settings will be found in the config file. Without such a change, every user needs to modify their editor integration with autogen on a per-repo basis, which is simply unsustainable.¹

Thus, the layering of settings would work as follows (from lowest to highest precedence):

• autogen built-in defaults
• repo-level configuration settings
• command-line flags and env vars set by the user

The config file needs to be automatically located within the current directory and parent directories, so that it's seamless to be found, without being specified via a path on the command line.

We can further consider an addition where we may adapt the notion of a root file, past which the parent-directory recursion will not proceed. This can be useful in cases where different directories may have different rules for the default flags, e.g., in the case of imported third-party libraries into a single source tree or other special arrangements.

Related work

For a similar idea in another project, see EditorConfig as well as CI systems like Travis and others use config files in the repo for their purposes.

Footnotes

¹ Note that the EditorConfig solution to the per-repo differences in indentation, tabs-vs-spaces, etc. is quite similar to the per-repo differences in licensing, copyright holder, #! lines, comment and test boilerplate, etc.

Right now, autogen includes a // TODO: add a file-level comment after the license boilerplate in the file. This also happens when using autogen -i to modify files in-place.

This should be made optional so that updates to existing files which may already have top-level comments can just add the license without the extra // TODO comment.