Request to include gconfd's m4 macro to next tarball for easy autoreconfing

[GoogleCodeExporter]

Request:

Please include .m4 macro file from GConf to next gecko-mediaplayer 
tarball for easy autoreconf.

Reason:

gecko-mediaplayer doesn't need full gconfd installed for autoreconf process
(which is often required after applying compability patches when new
xulrunner is released)

Example:

http://bugs.gentoo.org/301932

Original issue reported on code.google.com by ssuomi...@unk.fi on 31 Jan 2010 at 2:46

[GoogleCodeExporter]

Sorry, I will not do this as the .m4 macro does not belong in my source 
repository.
Please suggest an alternate solution.

Original comment by kdeko...@gmail.com on 31 Jan 2010 at 4:28

[GoogleCodeExporter]

I disagree since that's also the only way to ensure the macro is the version 
you need
it to be.

"It's always better inform upstream when the needed m4 files are missing in the
distribution, asking them to add all the needed files in the source tarball to 
avoid
version conflicts if the macro changes. " [1]

[1] http://devmanual.gentoo.org/general-concepts/autotools/index.html

There's no other proper solutions, so feel free to close this as 'wontfix' if 
you wish

Thanks, Samuli

Original comment by ssuomi...@unk.fi on 31 Jan 2010 at 10:21

[GoogleCodeExporter]

I made a change to SVN, that moves around the call to the macro, so the .m4 file
should only be needed if you are using gconf, please test.

Original comment by kdeko...@gmail.com on 1 Feb 2010 at 4:03

[GoogleCodeExporter]

Fixed in 0.9.9

Original comment by kdeko...@gmail.com on 10 Feb 2010 at 3:44

• Changed state: Fixed

[GoogleCodeExporter]

It doesn't pass ./configure anymore with 0.9.9:

configure: error: conditional "GCONF_SCHEMAS_INSTALL" was never defined.        

Usually this means the macro was only invoked conditionally.

So it's more broken now than before. Sorry for late response. :/

Original comment by ssuomi...@unk.fi on 10 Feb 2010 at 4:21

[GoogleCodeExporter]

This is already fixed in SVN... 

Original comment by kdeko...@gmail.com on 10 Feb 2010 at 4:23

[GoogleCodeExporter]

Indeed. You are correct, the --without-gconf thing is fixed in trunk.

But the original issue here isn't fixed, this is autoreconf without gconfd 
installed:

***** autoconf

configure.in:102: error: possibly undefined macro: AM_GCONF_SOURCE_2
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Original comment by ssuomi...@unk.fi on 10 Feb 2010 at 4:31

[GoogleCodeExporter]

Well I build configure with that macro already in it. So if you don't run 
autoreconf
or autogen and only use ./configure it should be fine from SVN or the tarball.

Original comment by kdeko...@gmail.com on 10 Feb 2010 at 4:34

[GoogleCodeExporter]

But 0.9.9 isn't usable (for Gentoo) without autoreconfing it first, with the
backported --without-gconf patch to configure.in, and here we end up in the same
situation we started with...

We also apply another patch which reorders the xulrunner/mozilla library 
detection
order, otherwise it picks up seamonkey-1 and fails. So we need autoreconf also 
for that.

And when new xulrunner is out... we likely need it for that too. 

Really, only way out of the problem is including the macro in the tarball ;)

Original comment by ssuomi...@unk.fi on 10 Feb 2010 at 4:41

[GoogleCodeExporter]

Since you are already patching it, why don't you add it or patch it out. I 
understand
why you think it should be in my source code. But I have a hard time adding 
files
that don't belong to me. That file belongs to gconf and if I add it my code 
then I
have to update it when gconf updates it, creating a hassle for me.

Original comment by kdeko...@gmail.com on 10 Feb 2010 at 4:46

[GoogleCodeExporter]

Is there a way in autoconf to only include a macro if it exists?

Original comment by kdeko...@gmail.com on 10 Feb 2010 at 5:32

[GoogleCodeExporter]

Now that the ordering of libxul has been changed upstream do you still need to 
run
autoreconf?

Original comment by kdeko...@gmail.com on 13 Feb 2010 at 2:43

[GoogleCodeExporter]

Nope. 

Until next xulrunner version and new incompability issues, only matter of time

Original comment by ssuomi...@unk.fi on 13 Feb 2010 at 3:56