Inkscape from CVS will not compile on Fedora Core 3
Hello, Everyone I have two or three threads on this issue over the past few weeks, but to avoid confusion, I will start a new one and treat it like it is a new issue (which it is not. Inkscape from CVS had been impossible to compile (for me, anyway) on Fedora Core 3 for a few weeks)
When I attempt to run "make" (after successfully completing "./autogen.sh" and "./configure") "make" bails with the following error: 2030 Making all in po 2031 make[2]: Entering directory `/home/steve/CVS/Assorted-CVS-Modules/inkscape/po' 2032 file=./`echo cs | sed 's,.*/,,'`.gmo \ 2033 && rm -f $file && /usr/bin/msgfmt -c -o $file cs.po 2034 file=./`echo es | sed 's,.*/,,'`.gmo \ 2035 && rm -f $file && /usr/bin/msgfmt -c -o $file es.po 2036 file=./`echo fr | sed 's,.*/,,'`.gmo \ 2037 && rm -f $file && /usr/bin/msgfmt -c -o $file fr.po 2038 file=./`echo it | sed 's,.*/,,'`.gmo \ 2039 && rm -f $file && /usr/bin/msgfmt -c -o $file it.po 2040 file=./`echo ja | sed 's,.*/,,'`.gmo \ 2041 && rm -f $file && /usr/bin/msgfmt -c -o $file ja.po 2042 ja.po:1889: message catalog has plural form translations... 2043 ja.po:12: ...but header entry lacks a "plural=EXPRESSION" attribute 2044 ja.po:1889: message catalog has plural form translations... 2045 ja.po:12: ...but header entry lacks a "nplurals=INTEGER" attribute 2046 Try using the following, valid for Japanese: 2047 "Plural-Forms: nplurals=1; plural=0;\n" 2048 make[2]: *** [ja.gmo] Error 1 2049 make[2]: Leaving directory `/home/steve/CVS/Assorted-CVS-Modules/inkscape/po' 2050 make[1]: *** [all-recursive] Error 1 2051 make[1]: Leaving directory `/home/steve/CVS/Assorted-CVS-Modules/inkscape' 2052 make: *** [all] Error 2
I have seen "make" bail on various *.po files while compiling Inkscape from CVS over the last few weeks, but otherwise the errors are just about the same.
Some additional information since my last message on this subject: I have done a fresh reinstall of Fedora Core 3, every package chosen and fully updated. "make" still bails with the same error while compiling Inkscape from CVS.
This next information might be VERY important (it is either just annoying, or maybe Very telling:) a recent attempt at compiling one of the release candidates for Inkscape 0.43 was COMPLETELY SUCCESSFUL! Imagine my "distress": 1. Just get done with another failed build of Inkscape from CVS. 2. Download and then successfully compile a pre-release that had just come from that same code. 3. Turn right around and attempt to re-compile Inkscape from CVS, and "make" still bails with the same error.
For the purpose of tracking this issue, I have filed a bug report: https://sourceforge.net/tracker/index.php?func=detail&aid=1343164&gr...
Also, if you would like to read all the information that I have sent to the list on this subject, here are links to the three threads that I have started on this issue: http://sourceforge.net/mailarchive/message.php?msg_id=13650891 http://sourceforge.net/mailarchive/message.php?msg_id=13690638 http://sourceforge.net/mailarchive/message.php?msg_id=13704598
Special message to Ben Fowler: I have not forgotten the things you told me to try in your last email to the list on this problem. I will soon incorporate them into an addition to this new thread.
Have a Great Day, Steven P. Ulrick
On 11/19/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
[ snip ]
This next information might be VERY important (it is either just annoying, or maybe Very telling:) a recent attempt at compiling one of the release candidates for Inkscape 0.43 was COMPLETELY SUCCESSFUL! Imagine my "distress":
Sephen, if you want to approach it from that angle then one possibility would be do a recursive diff and find out where the trees differ.
If you can approach your problem in a very logical fashion, you might be able to narrow this down to one or two source and configuration files and focus on those.
Ben
On Sat, 19 Nov 2005 18:03:46 +0300 Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 11/19/05, Ben Fowler wrote:
Sephen, if you want to approach it from that angle then one possibility would be do a recursive diff and find out where the trees differ.
Why on Earth? Just replace current ja.po with the old one
Alexandre
Hello, Everyone I will try replacing ja.po with an old version. But, I have tried that before (with the various different *.po files that "make" bails on) with no success. To clarify, I have tried to compile this with completely fresh downloads of Inkscape's CVS tree, with the same results: see the error message quoted in my first message on this thread. But I will gladly try it again.
Steven P. Ulrick
Steven P. Ulrick wrote:
On Sat, 19 Nov 2005 18:03:46 +0300 Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 11/19/05, Ben Fowler wrote:
Sephen, if you want to approach it from that angle then one possibility would be do a recursive diff and find out where the trees differ.
Why on Earth? Just replace current ja.po with the old one
I will try replacing ja.po with an old version. But, I have tried that before (with the various different *.po files that "make" bails on) with no success. To clarify, I have tried to compile this with completely fresh downloads of Inkscape's CVS tree, with the same results: see the error message quoted in my first message on this thread. But I will gladly try it again.
This seems kinda weird to me. (Sure I'm ignorant, I know that.) Does anyone else compile on FC3? Could it be the version of whatever is invoked by autogen.sh? Has that already been checked?
Aaron Spike
On Sat, 19 Nov 2005 10:52:42 -0600 aaron@...749... wrote:
Steven P. Ulrick wrote:
On Sat, 19 Nov 2005 18:03:46 +0300 Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 11/19/05, Ben Fowler wrote:
Sephen, if you want to approach it from that angle then one possibility would be do a recursive diff and find out where the trees differ.
Why on Earth? Just replace current ja.po with the old one
I will try replacing ja.po with an old version. But, I have tried that before (with the various different *.po files that "make" bails on) with no success. To clarify, I have tried to compile this with completely fresh downloads of Inkscape's CVS tree, with the same results: see the error message quoted in my first message on this thread. But I will gladly try it again.
This seems kinda weird to me. (Sure I'm ignorant, I know that.) Does anyone else compile on FC3? Could it be the version of whatever is invoked by autogen.sh? Has that already been checked?
Aaron Spike
Hello, Everyone I have discovered the following: The output of "./autogen.sh" and "./configure --prefix=/usr/local/", when run on Inkscape from CVS shows the version of intltool as 0.31.2: "autogen.sh" shows this: checking for intltool >= 0.17 ... yes (version 0.31.2) "configure" shows this: checking for intltool >= 0.22... 0.31.2 found For one thing, the minimum version of intltool that is being looked for is different. But that's not the interesting thing....
The output of "./configure --prefix=/usr/local/" when run in inkscape-0.42+0.43pre3 shows the version of intltool as being 0.33: checking for intltool >= 0.22... 0.33 found
Okay, so one would assume that I have two versions of intltool installed. So I did "rpm -qa | grep intltool" and discovered that the only version of intltool that I have installed is the one that is detected when compiling Inkscape from CVS.
So I proceeded to download intltool-0.33-2.src.rpm (which is the version that ships with Fedora Core 4) Did "rpmbuild --rebuild" on it and then did "rpm -Fvh" on the resulting RPM. When I re-ran "./autogen.sh" and "./configure", the version of "intltool" that was detected finally matched the version that is detected (but not installed on my machine) when I successfully compile Inkscape from an official release or pre-release tarball.
Now I get the following error: if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr//include/glib-2.0 -I/usr//lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/freetype2/config -DPOTRACE="potrace" -pthread -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr//include/gtk-2.0 -I/usr//lib/gtk-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr//include/glib-2.0 -I/usr//lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr//include/cairo -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gtkspell-2.0 -I../cxxtest -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT widgets/sp-color-preview.o -MD -MP -MF "widgets/.deps/sp-color-preview.Tpo" \ -c -o widgets/sp-color-preview.o `test -f 'widgets/sp-color-preview.cpp' || echo './'`widgets/sp-color-preview.cpp; \ then mv -f "widgets/.deps/sp-color-preview.Tpo" "widgets/.deps/sp-color-preview.Po"; \ else rm -f "widgets/.deps/sp-color-preview.Tpo"; exit 1; \ fi mv: cannot stat `widgets/.deps/sp-color-preview.Tpo': No such file or directory make[2]: *** [widgets/sp-color-preview.o] Error 1 make[2]: Leaving directory `/home/steve/CVS/Assorted-CVS-Modules/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/steve/CVS/Assorted-CVS-Modules/inkscape' make: *** [all] Error 2
This of course is completely different than the error that I have been getting. Now I'm going to try compiling from a fresh copy of Inkscape from CVS and see what happens.....
Steven P. Ulrick
On Sat, 19 Nov 2005 17:51:17 -0600 "Steven P. Ulrick" <lists-inkscape@...1052...> wrote:
On Sat, 19 Nov 2005 10:52:42 -0600 aaron@...749... wrote:
Steven P. Ulrick wrote:
On Sat, 19 Nov 2005 18:03:46 +0300 Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 11/19/05, Ben Fowler wrote:
Sephen, if you want to approach it from that angle then one possibility would be do a recursive diff and find out where the trees differ.
Why on Earth? Just replace current ja.po with the old one
I will try replacing ja.po with an old version. But, I have tried that before (with the various different *.po files that "make" bails on) with no success. To clarify, I have tried to compile this with completely fresh downloads of Inkscape's CVS tree, with the same results: see the error message quoted in my first message on this thread. But I will gladly try it again.
This seems kinda weird to me. (Sure I'm ignorant, I know that.) Does anyone else compile on FC3? Could it be the version of whatever is invoked by autogen.sh? Has that already been checked?
Aaron Spike
Hello, Everyone I have discovered the following: The output of "./autogen.sh" and "./configure --prefix=/usr/local/", when run on Inkscape from CVS shows the version of intltool as 0.31.2: "autogen.sh" shows this: checking for intltool >= 0.17 ... yes (version 0.31.2) "configure" shows this: checking for intltool >= 0.22... 0.31.2 found For one thing, the minimum version of intltool that is being looked for is different. But that's not the interesting thing....
The output of "./configure --prefix=/usr/local/" when run in inkscape-0.42+0.43pre3 shows the version of intltool as being 0.33: checking for intltool >= 0.22... 0.33 found
Okay, so one would assume that I have two versions of intltool installed. So I did "rpm -qa | grep intltool" and discovered that the only version of intltool that I have installed is the one that is detected when compiling Inkscape from CVS.
So I proceeded to download intltool-0.33-2.src.rpm (which is the version that ships with Fedora Core 4) Did "rpmbuild --rebuild" on it and then did "rpm -Fvh" on the resulting RPM. When I re-ran "./autogen.sh" and "./configure", the version of "intltool" that was detected finally matched the version that is detected (but not installed on my machine) when I successfully compile Inkscape from an official release or pre-release tarball.
Now I get the following error:
Hello, Everyone :) Success! Just compiled and installed Inkscape from CVS successfully. I guess my question would be, how did a version of intltool that was not installed on my computer get detected when compiling the release tarballs? Is there a version of intltool bundled with the tarball?
One thing I know for sure, I haven't been able to compile inkscape from CVS for weeks, then I discover this, update intltool to 0.33 and now it compiles perfectly :)
Have a Great Night, Steven P. Ulrick
Steven P. Ulrick wrote:
One thing I know for sure, I haven't been able to compile inkscape from CVS for weeks, then I discover this, update intltool to 0.33 and now it compiles perfectly :)
Cool, glad you got it figured out. That was all rather bewildering.
Aaron Spike
On 11/19/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
On Sat, 19 Nov 2005 10:52:42 -0600 aaron@...749... wrote:
Steven P. Ulrick wrote:
On Sat, 19 Nov 2005 18:03:46 +0300 Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 11/19/05, Ben Fowler wrote:
Sephen, if you want to approach it from that angle then one possibility ...
Why on Earth? Just replace current ja.po with the old one
But I will gladly try it again.
This seems kinda weird to me. (
I have discovered the following:
Now I get the following error: ... then mv -f "widgets/.deps/sp-color-preview.Tpo" "widgets/.deps/sp-color-preview.Po"; \ else rm -f "widgets/.deps/sp-color-preview.Tpo"; exit 1; \ fi mv: cannot stat `widgets/.deps/sp-color-preview.Tpo': No such file or directory
That error is probably owing to the directory referenced as 'widgets/.deps' not existing.
You could create that directory and retry.
Obviously something in autogen, configure or an upstream make should have created it.
When I get this problem I remove all files in the tree called 'Makefile' using find, and recreate them with configure.
Ben
On Sun, 20 Nov 2005 03:54:46 +0000 Ben Fowler <ben.the.mole@...400...> wrote:
On 11/19/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
On Sat, 19 Nov 2005 10:52:42 -0600 aaron@...749... wrote:
Steven P. Ulrick wrote:
On Sat, 19 Nov 2005 18:03:46 +0300 Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 11/19/05, Ben Fowler wrote:
Sephen, if you want to approach it from that angle then one possibility ...
Why on Earth? Just replace current ja.po with the old one
But I will gladly try it again.
This seems kinda weird to me. (
I have discovered the following:
Now I get the following error: ... then mv -f "widgets/.deps/sp-color-preview.Tpo" "widgets/.deps/sp-color-preview.Po"; \ else rm -f "widgets/.deps/sp-color-preview.Tpo"; exit 1; \ fi mv: cannot stat `widgets/.deps/sp-color-preview.Tpo': No such file or directory
That error is probably owing to the directory referenced as 'widgets/.deps' not existing.
You could create that directory and retry.
Obviously something in autogen, configure or an upstream make should have created it.
When I get this problem I remove all files in the tree called 'Makefile' using find, and recreate them with configure.
Ben
Hello, Ben After I got that error, I grabbed a fresh copy of Inkscape from CVS and recompiled, with complete success! Check out my comments in my message on this thread that has " - FIXED" appended to the end of the subject line. The release tarballs of Inkscape were "detecting" a version of intltool that does not come with FC3 and had never been installed on my system. Perhaps it is bundled with the Inkscape tarball? IF that is the case, it "could" account for the fact that I could compile from release tarballs but not from the CVS tree.
The only thing I know for sure is that a version of intltool that does not come with FC3 and that I did not install was somehow detected by the Inkscape compilation process, resulting in a perfect build (from a release tarball). Then I grabbed the SRPM of intltool from FC4 and rebuilt and updated to that version. The build attempt that you refer to in the message I am replying to immediately followed my upgrade to the FC4 version of intltool. I then got a fresh copy of Inkscape from CVS and SUCCESSFULLY compiled it :) The only known difference being the version of intltool installed from RPM on my system now matched the version that the Inkscape tarballs somehow had been detecting. How this happened, I have not a clue :) I "suspect" that that different error that I referred to in the message that you are replying to may have had to do with the, oh let's say different things I was grasping at trying to fix this. But I am sure that I have attempted compiling from fresh copies of Inkscape enough times (before and after a fresh install of FC3 last week) that the problem lies either with Fedora Core 3's version of intltool, or in Inkscape's detection of it. Oh yeah, check out a recent email of mine in this thread that shows that though autogen.sh and configure both find the same version of intltool, they seem to be looking for different versions. What all this means, I haven't a clue.....
Thank you very much for your interest and attention to this problem since I first brought it to this list. Steven P. Ulrick
On 11/20/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
On Sun, 20 Nov 2005 03:54:46 +0000 Ben Fowler <ben.the.mole@...400...> wrote:
... That error is probably owing to the directory referenced as 'widgets/.deps' not existing.
You could create that directory and retry.
Obviously something in autogen, configure or an upstream make should have created it.
When I get this problem I remove all files in the tree called 'Makefile' using find, and recreate them with configure.
Hello, Ben After I got that error, I grabbed a fresh copy of Inkscape from CVS and recompiled, with complete success! Check out my comments in my message on this thread that has " - FIXED" appended to the end of the subject line. The release tarballs of Inkscape were "detecting" a version of intltool that does not come with FC3 and had never been installed on my system. Perhaps it is bundled with the Inkscape tarball? IF that is the case, it "could" account for the fact that I could compile from release tarballs but not from the CVS tree.
Are you that you need intltool at all? I was under the impression that intltool was needed by translators (generating new .po and .pot files) and possibly some developers - when working form CVS; but just to compile from source, one only needs msgfmt, as per earlier mails.
I am not sure that I know exactly what you are doing!
Ben
On Sun, 20 Nov 2005 04:58:14 +0000 Ben Fowler <ben.the.mole@...400...> wrote:
Are you that you need intltool at all? I was under the impression that intltool was needed by translators (generating new .po and .pot files) and possibly some developers - when working form CVS; but just to compile from source, one only needs msgfmt, as per earlier mails.
I am not sure that I know exactly what you are doing!
Ben
Hello, Ben Well, let's see. What I am trying to do is find differences between the release tarballs and the CVS tree. One of the first differences that I found was relating to intltool. autogen.sh and configure picked up a version that was not installed on my system, so I upgraded to the FC4 version. Now inkscape compiles. Can I explain it? No. Now I am not saying that Inkscape requires intltool, but I have had Fedora Core specific problems before, so the blame could likely lie in the direction of Fedora, not Inkscape. But I do have an idea for three experiements that I am going to try: 1. I will uninstall intltool altogether and grab a fresh copy of Inkscape from CVS. I will see if/how Inkscape from CVS will compile without intltool installed.
The result was that autogen.sh bailed almost immediately with the following error:
I am testing that you have the required versions of libtool, autoconf, automake, glib-gettextize and intltoolize. This test is not foolproof and if anything goes wrong, there may be guidance in the file HACKING.txt
checking for autoconf >= 2.52 ... yes (version 2.59) checking for automake >= 1.7 ... yes (version 1.7.9) checking for glib-gettextize >= 2.0.0 ... yes (version 2.8.2) checking for intltool >= 0.17 ... You must have intltool installed to compile Inkscape. Get the latest version from ftp://ftp.gnome.org/pub/GNOME/sources/intltool/
Please install/upgrade the missing tools and call me again.
So autogen.sh bailed without intltool installed.
Just for fun, I ran ./configure in inkscape-0.42+0.43pre3, still without intltool installed. It STILL picks up version 0.33, which it seems to pick up on my system even when I don't have a version of it installed!
2. Now I will install the intltool that comes with FC3 and attempt to recompile. Ok, I just did "yum install intltool" and ran ./autogen.sh. This time autogen.sh did not bail, and it picked up the version that is installed when you install Fedora Core, which is the same one that was installed when I just ran "yum install intltool" I will have to wait awhile to see what happens. While I am waiting, I will be real annoyed at Fedora Core 3 if Inkscape from CVS won't compile this time, since the only difference on my system now is the version of intltool. Also, even if Inkscape is not supposed to depend on it, autogen.sh Does bail on my system when it is not installed.
The result was that "make" bailed with the following error, which is the same one that it has been bailing with for a few weeks now:
Making all in po make[2]: Entering directory `/home/steve/CVS/Assorted-CVS-Modules/inkscape/po' file=./`echo am | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr/bin/msgfmt -c -o $file am.po
<snip>
file=./`echo ja | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr/bin/msgfmt -c -o $file ja.po ja.po:1889: message catalog has plural form translations... ja.po:12: ...but header entry lacks a "plural=EXPRESSION" attribute ja.po:1889: message catalog has plural form translations... ja.po:12: ...but header entry lacks a "nplurals=INTEGER" attribute Try using the following, valid for Japanese: "Plural-Forms: nplurals=1; plural=0;\n" make[2]: *** [ja.gmo] Error 1 make[2]: Leaving directory `/home/steve/CVS/Assorted-CVS-Modules/inkscape/po' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/steve/CVS/Assorted-CVS-Modules/inkscape' make: *** [all] Error 2
3. Since steps one and two seem to show, respectively, that Inkscape from CVS will hardly even start to compile on my system if intltool is not installed, and that it will start, but not finish, if the version of intltool that ships with FC3 is installed, it follows that the next thing to try is grabbing a fresh copy of Inkscape from CVS, upgrade to intltool 0.33 from FC4 (which is the same version that an Inkscape release tarball picks up even if I have just did "rpm -e --nodeps intltool" as root. I risked --nodeps just for the sake of this experiment. The dependencies that came up from attempting to remove intltool from my FC3 system would have taken a good portion of GNOME with it.) and then re-compile with the FC4 version of intltool installed.
The results of step three are that Inkscape from CVS compiled & installed perfectly, just like it did the first time I updated my version of intltool.
My relatively unlearned conclusion to all of this is that maybe intltool is not Supposed to be required just to build and install Inkscape from CVS, but it's absence on MY system forces autogen.sh to bail mere seconds after it starts. And, upgrading via RPM to a version similar to the version that Inkscape release tarballs detect (which is NOT in my RPM data base, and is not installed with Fedora Core 3) at least seems to cause the end result of being able to successfully compile Inkscape from CVS on Fedora Core 3. This could very well be a Fedora Core 3 issue, I have not a clue.
Steven P. Ulrick
On 11/20/05, Steven P. Ulrick <lists-fedora@...1052...> wrote:
On Sun, 20 Nov 2005 04:58:14 +0000 Ben Fowler <ben.the.mole@...400...> wrote:
I am not sure that I know exactly what you are doing!
Well, let's see. What I am trying to do is find differences between the release tarballs and the CVS tree. ...
May I start with some general comments?
When a package is distributed in source form, it should (IHMO) contain a ./configure script so that a user can build it using these simple(!) commands:
$ ./configure $ make $ make test $ make -n install $ sudo make install
or the required subset.
However, developers working from CVS do not necessarily want the (generated) ./configure script under source control, in the repository.
See http://sources.redhat.com/ml/automake/2003-02/msg00038.html for a concise summary of this, which predates, BTW, the move from configure.in to configure.ac .
A search on Google has found no other accessible source for this info, and if you feel you need to be better informed, you might well want to review the 'Development Process' section of the Bean Book, particularly the pages from page 194.
Ob. dict. Although a little wordy the Bean Book is pretty much the only dead trees publication aimed at this level, and I would suggest that you get a copy of it, or the Turtle book http://www.oreilly.com/catalog/0596004486/colophon.html However, since I can't give an unmixed recommendation for either CVS or Subversion (most people would be better off with Mercurial, Monotone or Darcs), I must counsel you to be critical in reading either of those publications and not to get drawn into into details.
Now I am suggesting that most of the devs here have recent versions of autoconf and friends, a working intltool and the necessary libraries, and are able to generate the ./configure script.
It is not completely clear where you are having problems and whether these can be laid at the door of Fedora Core.
It is my belief that building Inkscape from CVS is not for the faint of heart. There are a large number of dependencies. See for example, the recent thread about gtkmm. You are very welcome to prove me wrong, of course. I would even suggest that you consider also working on an easier project. It would be a shame if you were put off contributing to open source graphic projects because of (admitted and very well known) infelicities in autotools which are nothing to do with graphics.
I am not sure that I could definitely say which have an easier learning curve and/or need help, but you might want to look at ImageMagick http://www.imagemagick.org/script/index.php , Tango http://www.actsofvolition.com/archives/2005/october/announcingthe , Scribus http://www.scribus.org.uk/ , Graphviz e.g. http://rootprompt.org/article.php3?article=9306 , and there are some others in Gnome that I don't know about, and perhaps dozens in Sourceforge.
I will deal with your other points later, if time permits: Otherwise you might find some help here http://gnome.org/~malcolm/i18n/
Ben
On 11/20/05, Steven P. Ulrick <lists-fedora@...1052...> wrote:
On Sun, 20 Nov 2005 04:58:14 +0000 Ben Fowler <ben.the.mole@...400...> wrote:
I am not sure that I know exactly what you are doing!
Hello, Ben Well, let's see. What I am trying to do is find differences between the release tarballs and the CVS tree.
I meant: By using the diff tool to list deleted, new and modified files and directories
One of the first differences that I found was relating to intltool. autogen.sh and configure picked up a version that was not installed on my system,
That would be configure. Whatever test configure ran, probably found an executable somewhere on your path, such as /usr/local that you weren't expecting.
For ./configure to find uninstalled software, would to a first approximation at least, require magic.
so I upgraded to the FC4 version. Now inkscape compiles. Can I explain it? No. Now I am not saying that Inkscape requires intltool, but I have had Fedora Core specific problems before, so the blame could likely lie in the direction of Fedora, not Inkscape. But I do have an idea for three experiements that I am going to try: 1. I will uninstall intltool altogether and grab a fresh copy of Inkscape from CVS. I will see if/how Inkscape from CVS will compile without intltool installed.
The result was that autogen.sh bailed almost immediately ...
Just for fun, I ran ./configure in inkscape-0.42+0.43pre3, still without intltool installed. It STILL picks up version 0.33, which it seems to pick up on my system even when I don't have a version of it installed!
See previous. See next.
- Now I will install the intltool that comes with FC3 and attempt to
recompile. Ok, I just did "yum install intltool" and ran ./autogen.sh. This time autogen.sh did not bail, and it picked up the version that is installed when you install Fedora Core, which is the same one that was installed when I just ran "yum install intltool" I will have to wait awhile to see what happens. While I am waiting, I will be real annoyed at Fedora Core 3 if Inkscape from CVS won't compile this time, since the only difference on my system now is the version of intltool. Also, even if Inkscape is not supposed to depend on it, autogen.sh Does bail on my system when it is not installed.
The result was that "make" bailed ...
- Since steps one and two seem to show, respectively, that Inkscape
from CVS will hardly even start to compile on my system if intltool is not installed, and that it will start, but not finish, if the version of intltool that ships with FC3 is installed, it follows that the next thing to try is grabbing a fresh copy of Inkscape from CVS, upgrade to intltool 0.33 from FC4 (which is the same version that an Inkscape release tarball picks up even if I have just did "rpm -e --nodeps intltool" as root. I risked --nodeps just for the sake of this experiment. The dependencies that came up from attempting to remove intltool from my FC3 system would have taken a good portion of GNOME with it.) and then re-compile with the FC4 version of intltool installed.
I am not an rpm maven, but I would advise against using --nodeps . You will find that a good portion of your entire system will have undefined behaviour!
The results of step three are that Inkscape from CVS compiled & installed perfectly, just like it did the first time I updated my version of intltool.
My relatively unlearned conclusion to all of this is that maybe intltool is not Supposed to be required just to build and install Inkscape from CVS, but it's absence on MY system forces autogen.sh to bail mere seconds after it starts. And, upgrading via RPM to a version similar to the version that Inkscape release tarballs detect (which is NOT in my RPM data base, and is not installed with Fedora Core 3) at least seems to cause the end result of being able to successfully compile Inkscape from CVS on Fedora Core 3. This could very well be a Fedora Core 3 issue, I have not a clue.
If time permits, could you confirm that you are now a happy camper?
You might want to start afresh with a completely pristine copy of the latest Fedora Core. If you are enthusiastic about these researchs, you might want to try Ubuntu instead, which is very well regarded.
Ben
Hello, Ben I wasn't going to reply to any more emails on this subject, but after I read the one this is in reply to, I could not resist. 1. For whatever reason, when I installed intltool 0.33, Inkscape finally compiled for the first time in weeks. Whether one is supposed to need Intltool at all to compile Inkscape from CVS, I don't know, but what I do know is that before I upgraded to Intltool 0.33, Inkscape would not compile. And that as soon as I did upgrade to Intltool 0.33, Inkscape compiled successfully. There is no question about these facts.
2. Whether Intltool is required to build Inkscape from CVS or not is not important right now. All I know is that when I ran rpm -e --nodeps on intltool, the compilation of Inkscape bailed during autogen.sh. Then I reinstalled the FC3 version of intltools and "make" bailed at the usual place. Then I upgraded BACK up to intltool 0.33, and Inkscape compiles perfectly. Why this was, I don't know, I just know that that is how it was.
Thank you for your help, Ben. I will not be continuing this subject any further. Also, if you want any clarification on anything that I have said in this email, contact me off list, as I shall be unsubscribing from this list. But like I said, feel free to contact me off list.
Have a Great Day :) Steven P. Ulrick
On 11/22/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
Hello, Ben I wasn't going to reply to any more emails on this subject, but after I read the one this is in reply to, I could not resist.
- For whatever reason, when I installed intltool 0.33, Inkscape
finally compiled for the first time in weeks. Whether one is supposed to need Intltool at all to compile Inkscape from CVS, I don't know, but what I do know is that before I upgraded to Intltool 0.33, Inkscape would not compile. And that as soon as I did upgrade to Intltool 0.33, Inkscape compiled successfully. There is no question about these facts.
That is fine; Fedora is not my platform and intltool is not something I have deep knowledge of, but with that in mind it looks a little as though we might want to add a stanza to the README noting that intltool
= 0.31 is recommended.
Thank you for your detective work here.
Ben
On Sat, 19 Nov 2005 14:55:21 +0000 Ben Fowler <ben.the.mole@...400...> wrote:
On 11/19/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
[ snip ]
This next information might be VERY important (it is either just annoying, or maybe Very telling:) a recent attempt at compiling one of the release candidates for Inkscape 0.43 was COMPLETELY SUCCESSFUL! Imagine my "distress":
Sephen, if you want to approach it from that angle then one possibility would be do a recursive diff and find out where the trees differ.
If you can approach your problem in a very logical fashion, you might be able to narrow this down to one or two source and configuration files and focus on those.
Ben
Hello, Ben It took me about five minutes to figure out that you meant for me to do a recursive diff on, for safety's sake, a fresh copy of Inkscape from CVS and a tarball that I have successfully compiled Inkscape from. If that works, then I will try the same thing with sylpheed-claws...... :)
Steven P. Ulrick
On 11/19/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
On Sat, 19 Nov 2005 14:55:21 +0000 Ben Fowler <ben.the.mole@...400...> wrote:
On 11/19/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
[ snip ]
If you can approach your problem in a very logical fashion, you might be able to narrow this down to one or two source and configuration files and focus on those.
Ben
Hello, Ben It took me about five minutes to figure out that you meant for me to do a recursive diff on, for safety's sake, a fresh copy of Inkscape from CVS and a tarball that I have successfully compiled Inkscape from. If that works, then I will try the same thing with sylpheed-claws...... :)
Do you mean I was unclear and that you wasted five minutes in interpreting what I wrote, or that it was just a five minute job to create the diff; if the latter, with what result?
Please tell us about sylpheed? Are you having the same problems with another package? If so, can this be laidf at the door of inkscape?
Ben
Steven P. Ulrick
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 22 Nov 2005 05:16:01 +0000 Ben Fowler <ben.the.mole@...400...> wrote:
On 11/19/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
On Sat, 19 Nov 2005 14:55:21 +0000 Ben Fowler <ben.the.mole@...400...> wrote:
On 11/19/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
[ snip ]
If you can approach your problem in a very logical fashion, you might be able to narrow this down to one or two source and configuration files and focus on those.
Ben
Hello, Ben It took me about five minutes to figure out that you meant for me to do a recursive diff on, for safety's sake, a fresh copy of Inkscape from CVS and a tarball that I have successfully compiled Inkscape from. If that works, then I will try the same thing with sylpheed-claws...... :)
Do you mean I was unclear and that you wasted five minutes in interpreting what I wrote, or that it was just a five minute job to create the diff; if the latter, with what result?
Please tell us about sylpheed? Are you having the same problems with another package? If so, can this be laidf at the door of inkscape?
Hello, Ben I never made any such accusations. I merely made a comparison: I can successfully compile release tarballs of Sylpheed claws, and I cannot compile Sylpheed-claws from CVS. There was nothing in what I said that sounded anything like that I was blaming Inkscape for Sylpheed problems.
Steven P. Ulrick
On 11/19/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
Hello, Everyone
When I attempt to run "make" ... 2052 make: *** [all] Error 2
I have seen "make" bail on various *.po files while compiling Inkscape from CVS over the last few weeks, but otherwise the errors are just about the same.
This looks the same as the problem you were seeing before. Can you isolate to one command in a specific directory (make -w and make -n will help) and note the exact error error message, preferably from a small or simple test case.
One of us can google for the text of the error message and work out from there what is going wrong.
Ben
On 11/19/05, Steven P. Ulrick <lists-inkscape@...1052...> wrote:
Hello, Everyone
This next information might be VERY important (it is either just annoying, or maybe Very telling:) a recent attempt at compiling one of the release candidates for Inkscape 0.43 was COMPLETELY SUCCESSFUL!
When you are working with a source tarball, do you get the po directory at all?
If so, does it have pre-built .gmo files?
If it does, then your build process would not be trying to make them.
If you wanted, you could check with 'make clean' and 'make distclean'; if you do the latter then you may end by blowing away that tree, since you will be using autogen.sh to re-create the configuration files.
(See my first response to you for details)
Ben
participants (4)
-
unknown＠example.com -
Alexandre Prokoudine -
Ben Fowler -
Steven P. Ulrick