On Mon, 20 Dec 2004 21:30:18 -0800, Carol Spears wrote:

On Mon, Dec 20, 2004 at 08:21:34PM -0800, Carol Spears wrote:

does it make sense that i need jade to work on images with a piece of free software that is not as free as jade or open jade?

this was a mistyped thought. it should be:

does it make sense that gimp, which is free and open depend on a rather large piece of software that is only open and not free?

I had the same problem this weekend: my CVS builds for Solaris and for some older Linux systems broke due to the new test for gtkdocize in autogen.sh and in the configure script. Until last week, it was sufficient for me to build the API docs on an up-to-date Linux system (Debian testing) and then skip that step for my CVS builds for Solaris and older Linux versions (Debian stable, SuSE 8.2). This allowed me to test the CVS builds without having to install all gtk-doc dependencies on the older systems for which I have to build and install all new packages from source.

I think that it would be better to have an option in autogen.sh and configure.in that allows the CVS users to skip the API doc generation. This would make it easier to test the latest version on multiple platforms without having to wait for a GIMP tarball or to install all gtk-doc dependencies.

-Raphaël

Hi,

Raphaël Quinet writes:

I think that it would be better to have an option in autogen.sh and configure.in that allows the CVS users to skip the API doc generation. This would make it easier to test the latest version on multiple platforms without having to wait for a GIMP tarball or to install all gtk-doc dependencies.

configure.in depends on gtkdocize being present and it uses macros that are defined in gtkdoc.m4 so there is no way to make this optional.

Sven

Hi,

Carol Spears writes:

i would like to build gimp without this additional (and un-needed by me) software.

Use a tarball then. If you are building GIMP from CVS you are a hacker and you need the tools that are required to build GIMP including the developer documentation.

Sven

Hi,

Carol Spears writes:

does it make sense that gimp, which is free and open depend on a rather large piece of software that is only open and not free?

The real point here is that, afaik, gtkdoc doesn't actually depend on Jade any longer. For quite a while the docs are generated from XML using xsltproc so it should very well be possible to install gtkdoc w/o having Jade installed. If this bothers you, perhaps ask the gtkdoc developers to update their dependencies and make the old and rarely used SGML mode optional?

Sven

Hi,

Carol Spears writes:

does it make sense that gimp, which is free and open depend on a rather large piece of software that is only open and not free?

The real point here is that, afaik, gtkdoc doesn't actually depend on Jade any longer. For quite a while the docs are generated from XML using xsltproc so it should very well be possible to install gtkdoc w/o having Jade installed. If this bothers you, perhaps ask the gtkdoc developers to update their dependencies and make the old and rarely used SGML mode optional?

It is possible - I built gtkdoc on Win32 without having Jade installed.

HTH, Michael

Hi,

"Michael Schumacher" writes:

It is possible - I built gtkdoc on Win32 without having Jade installed.

How did you trick the configure script into believing that jade was available? I had a quick look and it seems to check for openjade or jade and bails out if it can't find any of those. It would however probably be sufficient to provide it some arbitrary executable that's named openjade.

Sven

On Tue, 21 Dec 2004 12:07:55 +0100, Sven Neumann wrote:

Raphaël Quinet writes:

I think that it would be better to have an option in autogen.sh and configure.in that allows the CVS users to skip the API doc generation. This would make it easier to test the latest version on multiple platforms without having to wait for a GIMP tarball or to install all gtk-doc dependencies.

configure.in depends on gtkdocize being present and it uses macros that are defined in gtkdoc.m4 so there is no way to make this optional.

Would you accept a patch that could make it optional? I haven't tried this yet, but it should be possible to modify autogen.sh in such a way that (when given the appropriate option) it would supply a substitute for gtkdoc.m4 so that the configure script could be generated from configure.in without requiring every build machine to have a working gtkdoc. This would be a bit similar to the way the configure script itself uses the "missing" script when some commands are not installed on the build machine.

In another message, you wrote:

Use a tarball then. If you are building GIMP from CVS you are a hacker and you need the tools that are required to build GIMP including the developer documentation.

If you build the GIMP on multiple platforms, you only need the developer documentation once.

I have one machine (based on Debian testing) that can build the docs. I am happy with that and I would like to avoid having to set up gtkdoc on the other ones, especially on the old Solaris boxes that don't have any of the packages that gtkdoc depends on. Yet I would like to use the CVS version on these machines so that I can test (and maybe improve) the latest code without having to wait for a tarball. Also, with a tarball it is difficult to do "cvs diff" or "cvs log" while trying to track down how a bug could have appeared in a section of the code.

-Raphaël

Hi,

Raphaël Quinet writes:

Would you accept a patch that could make it optional?

Well, if it really bothers you. But you need gtkdoc anyway if you want to build any other library using it and there are lots of them (including glib and gtk+).

I haven't tried this yet, but it should be possible to modify autogen.sh in such a way that (when given the appropriate option) it would supply a substitute for gtkdoc.m4 so that the configure script could be generated from configure.in without requiring every build machine to have a working gtkdoc. This would be a bit similar to the way the configure script itself uses the "missing" script when some commands are not installed on the build machine.

No, I wouldn't accept such an ugly hack. If at all you'd modify acinclude.m4.

Sven

Hi,

Carol Spears writes:

how did all the hackers work on gimp last week without jade then?

Things change and the switch to gtkdocize was long overdue. I don't see why we should not benefit from the work of the gtkdoc team who have been improving the build setup quite a bit lately. We waited with this much too long. Of course I could continue to merge these changes manually into the eight Makefiles that are involved in building the docs. But then I don't see why I should go through that error-prone and time-consuming process again and again if there's also simple solution that fixes it once and for all. It also doesn't seem to be a problem for any of the many other projects using gtkdocize.

Sven

Sven Neumann wrote:

Hi,

"Michael Schumacher" writes:

It is possible - I built gtkdoc on Win32 without having Jade installed.

How did you trick the configure script into believing that jade was available? I had a quick look and it seems to check for openjade or jade and bails out if it can't find any of those. It would however probably be sufficient to provide it some arbitrary executable that's named openjade.

Looks like a false negative - there is an openjade.exe on my system, and it doesn't seem to be a dummy.

Michael

Hi,

Carol Spears writes:

you need jade to hack properly on gimp? sgml. you need sgml to hack on gimp.

i am sorry. i dont get it. perhaps if you explain the need for sgml to build cvs gimp.

See, I already explained that SGML is not needed, nor is Jade.

Sven

Hi,

one last try to explain it to you. GIMP doesn't need Jade. It needs gtkdoc to build the developer documentation. gtkdoc can work in two modes, the old-fashioned way of using it involves processing SGML and thus needs jade or, preferably, openjade. The newer way of building these docs uses DocBook XML which is processed using xsltproc (on which we depend anyway). Since gtkdoc allows both SGML and XML, the gtkdoc package depends on jade. It would probably be a good idea to make jade optional for the build of gtkdoc so that people like you, who are for whatever reason not able to get it installed, can still build and install a version of gtkdoc that would work with GIMP.

Sven

Hi,

Carol Spears writes:

i think that the mail list is not as fast as the exchange it is managing here.

I think you are reading the mails faster than you are able to understand them. Perhaps you should reread my mails since I am not going to explain this again.

Sven

Hi,

Carol Spears writes:

i can read that you contradict what you yourself wrote and the software in questions' README.

No, it doesn't. I said that gtkdoc depends on Jade but only for some mode of operation that we don't use and need. I also suggested that you politely ask the gtkdoc maintainers to make this mode optional so that gtkdoc can be installed w/o Jade.

I also wonder why you don't just 'apt-get install gtk-doc-tools".

Sven

Hi,

Sven Neumann wrote:

It would probably be a good idea to make jade optional for the build of gtkdoc so that people like you, who are for whatever reason not able to get it installed, can still build and install a version of gtkdoc that would work with GIMP.

One small addition... since gtkdoc only requires jade at build-time, and a binary installation of it works fine without jade when only using xml mode, the alternative is to not build gtkdoc from source at all, and install a binary.

Cheers, Dave.

On Tue, 21 Dec 2004 19:25:01 +0100, Sven Neumann wrote:

Raphaël Quinet writes:

Would you accept a patch that could make it optional?

Well, if it really bothers you. But you need gtkdoc anyway if you want to build any other library using it and there are lots of them (including glib and gtk+).

I haven't tried the new gtk+ 2.6 yet, but IIRC gtk+ 2.4 could be installed from tarballs without gtkdoc. On most of the "old" systems on which I install CVS GIMP for testing, I build gtk+ and its dependencies from the released tarballs because I only want to test the GIMP itself and I do not need to have the development version of the various libraries. I only try gtk+ from CVS on my development machine.

I haven't tried this yet, but it should be possible to modify autogen.sh in such a way that [...]

No, I wouldn't accept such an ugly hack. If at all you'd modify acinclude.m4.

OK, I will try to do it in a clean way. I will submit a proposed patch to Bugzilla as soon as I have some time to look at this (probably during this weekend, after X-mas). Then you can review it and tell me if I can commit it.

-Raphaël

Hi,

Raphaël Quinet writes:

I haven't tried the new gtk+ 2.6 yet, but IIRC gtk+ 2.4 could be installed from tarballs without gtkdoc.

You can also install GIMP from tarball w/o gtkdoc.

No, I wouldn't accept such an ugly hack. If at all you'd modify acinclude.m4.

OK, I will try to do it in a clean way. I will submit a proposed patch to Bugzilla as soon as I have some time to look at this (probably during this weekend, after X-mas). Then you can review it and tell me if I can commit it.

Fine.

Sven