Created attachment 195055 [details] [review]
Fix bug preventing projects with libtool to regenerate

Created attachment 195151 [details] [review]
project-wizard: Fix bug preventing projects with libtool to regenerate

I think AC_CONFIG_SRCDIR is better than AC_CONFIG_AUX_DIR, so the last thing in my previous patch is unnecessary.

Solution (Compared to current git master):
- configure.ac: Add AC_CONFIG_SRCDIR to make sure ltmain.sh is created, even
though config.guess and friends are not present
- configure.ac: Replace AM_PROG_LIBTOOL with LT_INIT
- configure.ac: Remove parameters in AM_INIT_AUTOMAKE, since this form is
deprecated.
- autogen.sh: Check for LT_INIT instead of AM_PROG_LIBTOOL

Review of attachment 195151 [details] [review]:

Thanks for your patch and your explanations but I'm not completely agree with them.

- AC_CONFIG_AUX_DIR
I think it is not needed to create ltmain.sh. I have created an empty directory and add a file named configure.ac containing only AC_INIT and that's enough to have libtoolize --force --copy copying ltmain.sh. So I think AC_CONFIG_AUX_DIR is not needed. Moreover its usage is not clear to me.

- AC_CONFIG_SRCDIR
Like the previous, I think it is not needed to create ltmain.sh. It seems that libtoolize doesn't check for this macro (but it checks for AC_CONFIG_AUX_DIR). I understand better its use but I rather think it's better to not add it to keep the configure script easier to understand.

- LT_INIT
I'm agree it is better to use the new macro.

- AM_INIT_AUTOMAKE
I'm agree too that it is better to use the new version. It makes the script a bit smaller too.

Then, we could perhaps use a much simpler autogen.sh script using autoreconf instead. The current one has the advantage that you can see all tools called in the right order on the other hand it's quite long. I don't really know what is better for a beginner.

Finally, I have no explanation for the initial issues (missing ltmain.sh). As far as I understand, it should works correctly even without any change. Perhaps you don't have the same version of libtoolize? I have version 2.2.6b here.

I tested it today, but I don't why, it now creates ltmain.sh even without AC_CONFIG_SRCDIR. I also tested it in Anjuta and creating a GTK+ project doesn't show any errors. I tried it in one of my project and it also worked without the macro! I also tried it a lot of times before I posted this bug.

But I'm sure I have this problem ever since I moved from Anjuta 3.0.3 from 2.32.x (about the time Ubuntu 11.04, which I use, is released). I only decided to file a bug since autogen.sh cannot regenerate my project unless run twice (which is annoying when cloning from git).

Maybe the problem is in my computer? Though I checked and there are no packages installed or updated in the last two days that is related to libtoolize. I also have 2.2.6b here.

I already lost the log files, so I can't show you what it shows, but it's something like this:

First run of autogen.sh (libtoolize part):
autoreconf: running: libtoolize --install --copy --force
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.

Second run (libtoolize part):
autoreconf: running: libtoolize --install --copy --force
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'

In the first run, automake will fail because it can't find ltmain.sh, which libtoolize will recreate in the second run.

It now shows the following:
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force 
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --install --copy --force
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./config.guess'
libtoolize: copying file `./config.sub'
libtoolize: copying file `./install-sh'
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:7: installing `./missing'
gpinstruct-analyzer/Makefile.am: installing `./depcomp'
autoreconf: Leaving directory `.'

I also want to use this opportunity to ask something, is this really necessary:
`m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])])'? GTK+ and other libraries I saw just use `AM_SILENT_RULES([yes])' after `AM_MAINTAINER_MODE'. I think the later is much simpler.

I think the top part of configure.ac templates can be like this:
--------------------------------------------------------------------------------
AC_INIT([+NameHLower+], [+Version+])
AC_CONFIG_HEADERS([config.h])

AM_INIT_AUTOMAKE
AM_MAINTAINER_MODE
AM_SILENT_RULES([yes])
--------------------------------------------------------------------------------

I also noticed that the part for gtk-doc is a lot shorter and simpler:
GTK_DOC_CHECK([1.11],[--flavour no-tmpl])
That's 29 lines to 1.

And a typo: `Internatinalization'.

This doesn't exists in libraries I checked, is this necessary?
IT_PROG_INTLTOOL([0.35.0])

These files contain nothing but added to projects:
intltool-extract.in
intltool-merge.in
intltool-update.in

I used GTK+ and ATK for these comparisons.

I think this bug should be closed now, since even in my computer the bug now doesn't exists, though I think it will be nice if the updates to configure.ac templates in terminal and minimal will be added to Anjuta.

(In reply to comment #4)
> I tested it today, but I don't why, it now creates ltmain.sh even without
> AC_CONFIG_SRCDIR. I also tested it in Anjuta and creating a GTK+ project
> doesn't show any errors. I tried it in one of my project and it also worked
> without the macro! I also tried it a lot of times before I posted this bug.

I trust you and I think AC_CONFIG_AUX_DIR (but not AC_CONFIG_SRCDIR) could probably have made a difference. Anyway, as we don't what's happen I prefer to keep the configure.ac as it is now.

> I also want to use this opportunity to ask something, is this really necessary:
> `m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])])'? GTK+ and other
> libraries I saw just use `AM_SILENT_RULES([yes])' after `AM_MAINTAINER_MODE'. I
> think the later is much simpler.

Yes, it was useful to avoid a failure if AM_SILENT_RULES was not existing. I think we don't need it anymore.

 
> I think the top part of configure.ac templates can be like this:
> AC_INIT([+NameHLower+], [+Version+])
> AC_CONFIG_HEADERS([config.h])
> 
> AM_INIT_AUTOMAKE
> AM_MAINTAINER_MODE
> AM_SILENT_RULES([yes])

Ok.


> I also noticed that the part for gtk-doc is a lot shorter and simpler:
> GTK_DOC_CHECK([1.11],[--flavour no-tmpl])
> That's 29 lines to 1.

Ok.


> And a typo: `Internatinalization'.

Ok.

 
> This doesn't exists in libraries I checked, is this necessary?
> IT_PROG_INTLTOOL([0.35.0])

It is needed to check that intltool is a least version 0.35. It is probably a quite old version, so I think we can remove this.


> These files contain nothing but added to projects:
> intltool-extract.in
> intltool-merge.in
> intltool-update.in

Ok, I will check.


> I think this bug should be closed now, since even in my computer the bug now
> doesn't exists, though I think it will be nice if the updates to configure.ac
> templates in terminal and minimal will be added to Anjuta.

I will keep this bug open until I fix the issues above, I will try to do it for the next stable release.

(In reply to comment #5)
> > This doesn't exists in libraries I checked, is this necessary?
> > IT_PROG_INTLTOOL([0.35.0])
> It is needed to check that intltool is a least version 0.35. It is probably a
> quite old version, so I think we can remove this.

This is needed to use intltool instead of gettext for internationalization.


I have implemented most of the changes discussed here.