After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 650930 - anjuta-3.x project wizard fails to detect autogen-5.11.x
anjuta-3.x project wizard fails to detect autogen-5.11.x
Status: RESOLVED FIXED
Product: anjuta
Classification: Applications
Component: plugins: project-wizard
git master
Other Linux
: Normal normal
: ---
Assigned To: Sébastien Granjoux
Anjuta maintainers
: 658687 697529 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-05-24 02:18 UTC by Alexandre Rostovtsev
Modified: 2013-04-08 16:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch for autogen-5.11 detection (1.13 KB, patch)
2011-05-24 02:20 UTC, Alexandre Rostovtsev
none Details | Review
better patch, replacing version matching code with a regex (1.81 KB, patch)
2011-05-24 19:11 UTC, Alexandre Rostovtsev
reviewed Details | Review
patch with capturing regex (2.22 KB, patch)
2011-05-24 20:49 UTC, Alexandre Rostovtsev
committed Details | Review

Description Alexandre Rostovtsev 2011-05-24 02:18:07 UTC
Autogen-5.11 uses a different version string format that autogen-5.9:

autogen (GNU AutoGen) 5.11.9
vs.
autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.9.7

As a result, anjuta's project wizard fails to detect autogen and refuses ro run.

Fortunately, all versions of autogen use the longer version of the string in their usage description. So we can detect modern versions of autogen simply by replacing autogen -v with autogen -u.
Comment 1 Alexandre Rostovtsev 2011-05-24 02:20:27 UTC
Created attachment 188430 [details] [review]
patch for autogen-5.11 detection

This patch (replacing the call to "autogen -v" with "autogen -u") allows anjuta to correctly detect both autogen-5.11.9 and autogen-5.9.7 on my system.
Comment 2 Sébastien Granjoux 2011-05-24 17:35:24 UTC
Thanks for reporting this.

But don't you think it will be better to keep using "autogen -v" and use a regular expression to check the version number?

I would work even if the autogen string is changing again.
Comment 3 Alexandre Rostovtsev 2011-05-24 19:11:06 UTC
Created attachment 188507 [details] [review]
better patch, replacing version matching code with a regex

(In reply to comment #2)

You're right, a regex would be better. Here is a patch that does that. I believe it should match everything from autogen-5.5.x (the oldest version available from autogen's ftp) to the current 5.11.x releases.
Comment 4 Sébastien Granjoux 2011-05-24 19:51:09 UTC
Review of attachment 188507 [details] [review]:

Thank again for your fast reaction.

I would prefer that you extract the version number from the version string as it was done before in ver array and then just check if the major number is 5. It would be easier if we have to check for a particular version number later. Then, I would have checked only the string "autogen" instead of "GNU AutoGen" and "The Automated Program Generator" but you can keep it like this.
Comment 5 Alexandre Rostovtsev 2011-05-24 20:49:03 UTC
Created attachment 188524 [details] [review]
patch with capturing regex

(In reply to comment #4)

OK, here is a patch with a regex that checks for "autogen" and captures the version number. You can implement checks for the major, minor, and micro version numbers by looking at match_strings[1], match_strings[2], and match_strings[3] respectively (note that match_strings[3] may not exist).
Comment 6 Sébastien Granjoux 2011-05-25 19:11:56 UTC
Review of attachment 188524 [details] [review]:

Thanks for your patch, I have committed it. I have just made a small change to extract the full version number in a int array like it was done before.
Comment 7 Sébastien Granjoux 2011-09-10 06:28:52 UTC
*** Bug 658687 has been marked as a duplicate of this bug. ***
Comment 8 Sébastien Granjoux 2013-04-08 16:38:05 UTC
*** Bug 697529 has been marked as a duplicate of this bug. ***