lgplv3-comment breaks autorevision when used with ./configure ...

[Jenna]

autorevision.cpp expects to find a comment with the (svn-)revision in the first line of autorevision.h, but the lgplv3-comment is placed before it.

In addition, the comment is missing from the header-file generated by autorevision.cpp if the revision has changed (or autorevision believes it has changed).

Here is a patch that fixes both issues:

Code

--- codeblocks-1.0svn.orig/src/include/autorevision.h.in        2008-03-01 09:43:53.000000000 +0100
+++ codeblocks-1.0svn.work/src/include/autorevision.h.in        2008-03-02 00:33:02.000000000 +0100
@@ -1,9 +1,9 @@
+/*@REVISION@*/^M
 /*^M
  * This file is part of the Code::Blocks IDE and licensed under the GNU Lesser General Public License, version 3^M
  * http://www.gnu.org/licenses/lgpl-3.0.html^M
  */^M
 ^M
-/*@REVISION@*/^M
 #ifndef AUTOREVISION_H^M
 #define AUTOREVISION_H^M
 ^M
--- codeblocks-1.0svn.orig/src/build_tools/autorevision/autorevision.cpp        2008-03-01 09:18:46.000000000 +0100
+++ codeblocks-1.0svn.work/src/build_tools/autorevision/autorevision.cpp        2008-03-02 00:37:42.000000000 +0100
@@ -163,6 +163,10 @@
     }

     fprintf(header, "%s\n", comment.c_str());
+    fprintf(header, "/*\n");
+    fprintf(header, " *  * This file is part of the Code::Blocks IDE and licensed under the GNU Lesser General Public License, version 3\n");
+    fprintf(header, " *   * http://www.gnu.org/licenses/lgpl-3.0.html\n");
+    fprintf(header, " *    */\n");
     fprintf(header, "//don't include this header, only configmanager-revision.cpp should do this.\n");
     fprintf(header, "#ifndef AUTOREVISION_H\n");
     fprintf(header, "#define AUTOREVISION_H\n\n\n");

Please consider when trying to apply the patch that the "^M"'s in the above patch are dos-lineednings as seen by vi.

[thomas]

Those are no issues, no patch needed. Just delete autorevision.h.

I wonder how the GPLv3 comment got into that file in the first place, though. Anyway, just delete that file, and everything will be good.

[Jenna]

Those are no issues, no patch needed. Just delete autorevision.h.

I tried this of course, but that does not (and can not) work.

The lgplv3-comment is in autorevision.h.in.
Running ./configure creates autorevision.h and expands @REVISION@ and @DATE@.
At compiletime, after creating the executable auto_revision, it is called from it's Makefile:

Code

all-local: auto_revision
        ./auto_revision +int +wx +t $(top_srcdir) $(top_srcdir)/src/include/autorevision.h

and looks for the revision number in the command comment in the first line of autorevision.h .

If it's not found there, or less then the revision number gathered from svn-command, it writes a new autorevision.h.
But if it's build from a source-tree without svn-informations (like I do for my nightlies to keep the tar-balls small) "0" is taken for the revision and "unknown date" for the date.
And that is an issue.

I wonder how the GPLv3 comment got into that file in the first place, though. Anyway, just delete that file, and everything will be good.

It's there since svn 4910: http://svn.berlios.de/wsvn/codeblocks/trunk/src/include/autorevision.h.in?op=diff&rev=4910&sc=1 .
/*@REVISION@*/ should be in the first line, because the WriteOutput-function in autorevision.cpp looks for the revision in the first line.

The second part of the patch is to ensure that the lgplv3-comment is also in the header if it is auto-generated by WriteOutput, because it belongs in the header oif course.

[thomas]

Let me clarify. First of all, the GPLv3 notice in autorevision.cpp as well as the "part of Code::Blocks" sentence is technically wrong (it's "GPLv2 or later", and it is not part of Code::Blocks). However, I don't really mind what license it is, so let's just leave that as it is.

The file autorevision.h has no license at all, and it shouldn't have one. While autorevision was programmed with Code::Blocks in mind (and has seen some modifications due to specific needs), it wasn't made especially and exclusively for just this one project. It was written as a (micro-)tool to get a revision number hardcoded into a program automatically. That was at a time when no such thing existed otherwise (in the mean time, there are a few tools that do the same, and better).
Someone who uses autorevision in a different project (which might not be GPL compatible at all) may not want to have his files automatically tagged with a GPL license.
Also, autorevision.h does not contain any original work, it is merely a file that is generated from a project's revision number, so it is really not justifiable to attach a license to it. If that was the case, one could argue that every project managed with Subversion falls under the Subversion license, too.

I don't know exactly what autorevision.h.in does (since I'm no autotools user). In fact, I didn't even know it was there
Apparently, it is meant to mimic/provide an autorevision.h file for tarballs  (I faintly remember someone did something for that some time in the past).
To address your problem, one solution would be to move the comment to the end of the .in file or remove it alltogether, both of which will make the file compliant. The other (probably better) solution would be to either use the .in file or run autorevision, but not both.

[afb]

I don't know exactly what autorevision.h.in does (since I'm no autotools user). In fact, I didn't even know it was there
Apparently, it is meant to mimic/provide an autorevision.h file for tarballs  (I faintly remember someone did something for that some time in the past).

Correct. :-)
Unfortunately it doesn't seem to work at the moment (as per above),
and there's also the issue of configure thinking the version is "1.0"

The packages that do get the correct version usually patches out
the call to autorevision, or generate their own tarballs, or both...

[Jenna]

As I wrote above the comment with the lgplv3 notice exists in autorevision.h.in.
It came in in svn4910 by Morten.

The .in is needed to generate the autorevision.h when running ./configure.
in the .in there are two "variables" that get replaced with the actual svn-revision and date.

The Makefile in the autorevision-subdir first creates the auto_revision-executable and then runs it.

auto_revision checks the version-number in the block-comment in the first line in autorevision.h.
And if it is not satisfied it creates a new one.

The only thing I wrote, is that the version-number should be in the first line. I have a patch that gets automatically applied when building my deb-binaries, so it's no problem for me, after I figured it out.

Nevertheless the placement of the comment breaks the function of autorevision if it is used in a none-svn subdir.

I didn't place the lgplv3-comment in the in-file, but afaik: all header and cpp files are switched to gplv3 ore lgplv3.

If it is not possible to change it without a bug-report, I will file one.

To repair the bug is quite easy, either the comment is totally removed, or placed after the variable to b substituted.
I don't know where the problem is to understand this.

I have an ill child at home, and therefore did not sleep much last night. I feel really bad today, cause I get ill myself.

I spent much to much time in writing redundant posts about the same issue.

I don't want to talk about this problem any more.

Sorry, if my words are too hard.

[thomas]

To repair the bug is quite easy, either the comment is totally removed, or placed after the variable to b substituted.
I don't know where the problem is to understand this.

This is exactly what I said, but I object to patching autorevision.cpp as you suggested.

[afb]

I think the header snuck in by accident in the GPL upgrade just before release,
so the fix is just reverting autorevision.h.in to match the expected header style...

[afb]

Fixed in r4926, removed GPL boilerplate and added comment to match the other autorevision.h.

[afb]

I have a patch that gets automatically applied when building my deb-binaries, so it's no problem for me, after I figured it out.

Fedora packaging also has such a patch, so it seems the plan to fix autorevision when svn is not available (such as when building from a tarball) by using autoconf has somewhat failed - those paches shouldn't be needed.

[Jenna]

I have a patch that gets automatically applied when building my deb-binaries, so it's no problem for me, after I figured it out.

Fedora packaging also has such a patch, so it seems the plan to fix autorevision when svn is not available (such as when building from a tarball) by using autoconf has somewhat failed - those paches shouldn't be needed.

For me it's just a patch to put /*@REVISION@*/ back in first line, but it's not needed any longer.
Thanks !

[afb]

Fedora packaging also has such a patch, so it seems the plan to fix autorevision when svn is not available (such as when building from a tarball) by using autoconf has somewhat failed - those paches shouldn't be needed.

For me it's just a patch to put /*@REVISION@*/ back in first line, but it's not needed any longer.
Thanks !

Hmm, seems like the patch isn't used in the latest "devel" package there either so maybe there is hope :-)

http://cvs.fedora.redhat.com/viewcvs/rpms/codeblocks/devel/