Are you trying to build Anjuta iself ?

I suppose yes. But the build autotools plugin provides a graphical interface to build any program and it's nothing to do with building Anjuta.

Then, when building Anjuta, I think introspection support is disabled by using --enable-introspection=no not --disable-introspection.

I chose "plugins: build-basic-autotools" as it was the only component related with "build system" I could find :-/, but I am not sure if it's the proper one.

About configure problem, I already tried with --enable-introspection=?, but also fails since configure doesn't contain any introspection trace after that:

$ ./configure --enable-introspection=no
configure: WARNING: unrecognized options: --enable-introspection
checking for a BSD-compatible install... /usr/bin/install -c
...

(In reply to comment #2)
> I chose "plugins: build-basic-autotools" as it was the only component related
> with "build system" I could find :-/, but I am not sure if it's the proper one.

Ok, so it's not the right one, but it doesn't matter, thanks for your report anyway :)


> About configure problem, I already tried with --enable-introspection=?, but
> also fails since configure doesn't contain any introspection trace after that:
> 
> $ ./configure --enable-introspection=no
> configure: WARNING: unrecognized options: --enable-introspection
> checking for a BSD-compatible install... /usr/bin/install -c
> ...

I think I have the explanation. There is a check in the configure file which is disabling the introspection support completely (including the --enable-introspection command line option) if the needed macro is not found. So I think you don't have the macros GOBJECT_INTROSPECTION_CHECK on your system (part of gobject-introspection).

It worked :-D, shipping introspection.m4 lets it work fine. Thanks a lot

I leave this open to let you decide its resolution since I am not sure if making downstream handle this when running autoreconf (in this case due bug #633661) is the proper way to go or not.

Best regards :-)

(In reply to comment #4)
> I leave this open to let you decide its resolution since I am not sure if
> making downstream handle this when running autoreconf (in this case due bug
> #633661) is the proper way to go or not.

Well, I don't know what is the normal solution for this. Do you know if other packages ship introspection.m4 ?
This file is normally installed by gobject-introspection package, what's happen if this macro is improved ?

I have only seen libwnck requiring us to provide introspection.m4 to run eautoreconf before anjuta :-/

I have reread all messages and I'm not sure it's needed that you ship introspection.m4 with Anjuta.

This file is installed with gobject-introspection package. So if you have installed it, you already have it and can disable or enable introspection. If you don't have gobject-introspection, you will not be able to build Anjuta with introspection support anyway so you don't need this option.

It makes a warning but I don't think it's better to ship introspection.m4. I suppose it will override the macros installed by gobject-introspection and if gobject-introspection is updated it could generate an error.

Do you agree with this or do I have missed something ?

From a downstream point of view, we still need to provide introspection.m4 when we need to run autoreconf after applying a patch affecting to Makefile.am or configure.ac for example :-/

Also, looks like behavior on 2.32.1.0 is a bit different, now, if I run ./configure from fresh upstream sources, --{enable,disable}-introspection option is not even recognized, needing to run autoconf to get it again. It's a headache for us at Gentoo since we let out users switch between introspection support passing --{disable,enable}-introspection option as desired

(In reply to comment #9)
> Also, looks like behavior on 2.32.1.0 is a bit different, now, if I run
> ./configure from fresh upstream sources, --{enable,disable}-introspection
> option is not even recognized, needing to run autoconf to get it again.

I think comparing to 2.32.0 nothing has changed and even before I have added the patch that makes --{enable,disable}-introspection disappear 27 of June.


> It's a
> headache for us at Gentoo since we let out users switch between introspection
> support passing --{disable,enable}-introspection option as desired

Sure, I'm trying to find the rigth solution and I don't understand the problem. For me, you can still use --{disable,enable}-introspection you will get a warning if it's not possible to build introspection support. By adding introspection.m4, you will get no warning but a build error if gobject-introspection is not installed.


You need to make the distribution package on a system where gobject-introspection is installed, else you will not get the option in the configure script. Indeed you don't get an error here, perhaps you prefer to get an error ? libwnck should give you an error by example but it's the same for most package supporting introspection. Or do you know a package supporting introspection without needing introspection.m4 ?

There could be some difference if I regenerated the tarball for 2.32.1 with a different gobject-introspection version which is quite possible.

Nevertheless, shipping introspection.m4 is not a solution because this file would need to be up-to-date with latest introspection and this is a pain.

The problem is likely to only affect gentoo and only if the end-user (not the package maintainer) needs to regenerate configure.ac. In any case, I doubt there should be any gentoo specific patches that affect Makefiles/configure.ac - please just push those upstream.

Thanks!

Sébastien, doing the check in the absence of gobject-introspection won't result in an error. All other GNOME packages that I know of ship introspection.m4 and have an unconditional call to GOBJECT_INTROSPECTION_CHECK and if g-i isn't available, it'll just not set HAVE_INTROSPECTION.

The only real case I can make for shipping introspection.m4 is to avoid confusion. If someone is building from git and does not have gobject-introspection installed, they might never even find out that Anjuta does support g-i, or might spend some time trying to figure out why they don't see that option at all. And maybe that it's nice to get the same set of options independent of what is installed on your system (admittedly subjective).

In Gentoo, based on USE-flags, we will always need to pass --enable-introspection or --disable-introspection to configure (otherwise we have no way of determining what options a user has built the package with). In the worst case, we'll just have to live with the warning generated by the missing configure option (which results in a QA warning being generated by our package manager).

All that said, I do agree with you about the merits of not having every package ship that file (though this is the case now anyway). :)

From a downstream perspective (not only gentoo), it is better to have all non-standard m4 files that the package needs (that is anything from gnome-doc-utils, autoconf-archive, introspection, mm-common, ...) in order to be sure that if downstream needs to re-generate the autotools because of a local patch (maybe something that's already fixed in master btw), downstream needs to be sure that it is using the same version of the macros used to distribute the tarball in the first place in order to minimize possibilities of incompatible m4 files usage.

To say it in a simpler way, this is the only way to ensure downstream can regenerate the most similar configure/Makefiles from the tarball.

(In reply to comment #13)
> All other GNOME packages that I know of ship introspection.m4 and
> have an unconditional call to GOBJECT_INTROSPECTION_CHECK and if g-i isn't
> available, it'll just not set HAVE_INTROSPECTION.

Well, I have looked at some random packages on gnome git repositories:
* ephiphany and gdk-pixbuf ships introspection.m4
* gtk-vnc and evince have their own check (it's like shipping introspection.m4)
* totem, nautilus, gedit, gnome-panel, gtksourceview, vinagre don't ship introspection.m4. The option will not be here if you don't have g-i installed and the build will probably fails (it happens in anjuta at automake state with few informations).


I have tried to compile gedit to see what error I get without introspection and I see that autogen.sh copy a bunch of .m4 files in gedit m4 directory. So isn't it the job of autotools to copy all necessary macros files in the m4 directory ?

It doesn't include introspection.m4 though, but perhaps there is something to fix.

we spoke to release team a couple of days ago and we agreed it was something to fix in gnome-common which provides autogen.sh, once this is fixed we will ask you to update this file and everyone will be happy :)

I don't think gnome-common is the right place. If it really is required to ship it elsewhere than g-i itself, bug 615518 proposes to add this .m4 to glib.

well, gtk-doc macro isn't provided by gnome-common as well. I don't think there is a big difference and in any case this needs to end up in the released tarball.

The released tarball has always been fine. This is just a problem if somebody runs autogen.sh on a system that doesn't have gobject-introspection installed.

If the tarballs are broken it is indeed a bug all recent tarballs should be fine.

Hey,

(In reply to comment #18)
> The released tarball has always been fine. This is just a problem if somebody
> runs autogen.sh on a system that doesn't have gobject-introspection installed.

I believe that, today, this is not a problem even if the person is using git instead of a tarball (and doesn't have gobject-introspection), because the call to GOBJECT_INTROSPECTION_CHECK is now wrapped in a m4_ifdef block.

The change that made it inside that m4_ifdef block was a bugfix to bug 622526, so I'm going to assume then that this is a duplicate. Don't hesitate to reopen if you think I'm mistaken.

*** This bug has been marked as a duplicate of bug 622526 ***