Menu
▾
▴
scrollkeeper-devel
|
From: Chee B. H. <cb...@mi...> - 2003-12-03 03:42:11
Attachments:
scrollkeeper.h.in.patch
|
Hi guys,
I am quite new to list. I recently installed scrollkeeper-0.3.12, but i
found a problem for it.
the file `scrollkeeper.h.in` in `libs`, after configure, will substitute
into scrollkeeper.h, however, the content:
#define SCROLLKEEPERLOGFILE "@localstatedir@/log/scrollkeeper.log"
#define SCROLLKEEPERLOGFILE_ROT "@localstatedir@/log/scrollkeeper.log.1"
will be substituted into (scrollkeeper.h):
#define SCROLLKEEPERLOGFILE "${prefix}/var/log/scrollkeeper.log"
#define SCROLLKEEPERLOGFILE_ROT "${prefix}/var/log/scrollkeeper.log.1"
Look at the Makefile.am, the correct scrollkeeper.h.in should be:
#define SCROLLKEEPERLOGFILE SCROLLKEEPER_STATEDIR"/log/scrollkeeper.log"
#define SCROLLKEEPERLOGFILE_ROT \
SCROLLKEEPER_STATEDIR"/log/scrollkeeper.log.1"
So the value can be substituted correctly into the scrollkeeper.h.in
Any idea?
regards,
HOH
--
Chee Bin HOH <cb...@gn...>, http://community.asiaosc.org/~cbhoh
Where we're going, we don't need roads..., http://www.gnome.org
Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
|
|
From: Malcolm T. <ma...@co...> - 2003-12-03 04:31:37
|
On Wed, 2003-12-03 at 14:37, Chee Bin HOH wrote:
> Hi guys,
>
> I am quite new to list. I recently installed scrollkeeper-0.3.12, but i
> found a problem for it.
>
> the file `scrollkeeper.h.in` in `libs`, after configure, will substitute
> into scrollkeeper.h, however, the content:
>
> #define SCROLLKEEPERLOGFILE "@localstatedir@/log/scrollkeeper.log"
> #define SCROLLKEEPERLOGFILE_ROT "@localstatedir@/log/scrollkeeper.log.1"
>
>
> will be substituted into (scrollkeeper.h):
>
> #define SCROLLKEEPERLOGFILE "${prefix}/var/log/scrollkeeper.log"
> #define SCROLLKEEPERLOGFILE_ROT "${prefix}/var/log/scrollkeeper.log.1"
This is fixed in CVS and I am rolling the 0.3.14 release right this
minute ('make distcheck' is running). The only hold up is that I have
had to fix a bug in intltool first, but I think that is done.
So wait a couple of hours and grab the 0.3.14 release (at no extra
charge, you get about two dozen other bug fixes as well).
Cheers,
Malcolm
|
|
From: Malcolm T. <ma...@co...> - 2003-12-03 12:08:21
|
On Wed, 2003-12-03 at 15:31, Malcolm Tredinnick wrote:
[...]
> This is fixed in CVS and I am rolling the 0.3.14 release right this
> minute ('make distcheck' is running). The only hold up is that I have
> had to fix a bug in intltool first, but I think that is done.
>
> So wait a couple of hours and grab the 0.3.14 release (at no extra
> charge, you get about two dozen other bug fixes as well).
OK, wait a few hours more. The intltool problem is not solved completely
(scrolkeeper's distcheck still fails). I need to sleep now and pick this
up again tomorrow.
Malcolm
|
|
From: Christian M. <mar...@wa...> - 2003-12-04 19:45:53
|
Malcolm Tredinnick <ma...@co...> writes:
> On Wed, 2003-12-03 at 15:31, Malcolm Tredinnick wrote:
> [...]
>> This is fixed in CVS and I am rolling the 0.3.14 release right this
>> minute ('make distcheck' is running). The only hold up is that I have
>> had to fix a bug in intltool first, but I think that is done.
>>
>> So wait a couple of hours and grab the 0.3.14 release (at no extra
>> charge, you get about two dozen other bug fixes as well).
>
> OK, wait a few hours more. The intltool problem is not solved completely
> (scrolkeeper's distcheck still fails). I need to sleep now and pick this
> up again tomorrow.
Do you want help ?
Christian
|
|
From: Malcolm T. <ma...@co...> - 2003-12-05 00:41:13
|
On Fri, 2003-12-05 at 06:45, Christian Marillat wrote:
> Malcolm Tredinnick <ma...@co...> writes:
>
> > On Wed, 2003-12-03 at 15:31, Malcolm Tredinnick wrote:
> > [...]
> >> This is fixed in CVS and I am rolling the 0.3.14 release right this
> >> minute ('make distcheck' is running). The only hold up is that I have
> >> had to fix a bug in intltool first, but I think that is done.
> >>
> >> So wait a couple of hours and grab the 0.3.14 release (at no extra
> >> charge, you get about two dozen other bug fixes as well).
> >
> > OK, wait a few hours more. The intltool problem is not solved completely
> > (scrolkeeper's distcheck still fails). I need to sleep now and pick this
> > up again tomorrow.
>
> Do you want help ?
It is nearly there now, thanks. The problem is making intltool work
properly with automake >= 1.6 and gettext 0.12 (for a variety of
reasons, the old gettext stuff we were shipping with scrollkeeper was
causing more problems than it was solving). Intltool is pretty broken
w.r.t that kind of setup (a known problem that nobody has really been
motivated enough to fix), so it has taken a lot of tweaking and running
'make distcheck' over and over again to get it working. I think I have
nailed it now, though.
The stupid thing is that this is a lot of effort for only one release.
There is a lot of code in scrollkeeper that becomes easier to maintain
(and removes a lot of bugs and becomes more portable) if I introduce a
dependency on glib (which is so commonly available now that I am not
worried about doing so). That will require people to already have a
gettext setup that works and then I can just use the glib gettext stuff
and all is simpler. But I don't want to make that change yet, since it's
pretty invasive, so it's for the next release.
Cheers,
Malcolm
|
|
From: Christian M. <mar...@wa...> - 2003-12-05 08:55:37
|
Malcolm Tredinnick <ma...@co...> writes: > On Fri, 2003-12-05 at 06:45, Christian Marillat wrote: [...] >> Do you want help ? > > It is nearly there now, thanks. The problem is making intltool work > properly with automake >= 1.6 and gettext 0.12 (for a variety of > reasons, the old gettext stuff we were shipping with scrollkeeper was > causing more problems than it was solving). Intltool is pretty broken > w.r.t that kind of setup (a known problem that nobody has really been > motivated enough to fix), so it has taken a lot of tweaking and running > 'make distcheck' over and over again to get it working. I think I have > nailed it now, though. You have a problem with intltool because you are using an unreleased version 0.28. The latest intltool is 0.27.2 : http://ftp.gnome.org/pub/GNOME/sources/intltool/0.27/ Christian |
|
From: Malcolm T. <ma...@co...> - 2003-12-05 11:56:48
|
On Fri, 2003-12-05 at 19:55, Christian Marillat wrote: [...] > You have a problem with intltool because you are using an unreleased > version 0.28. The latest intltool is 0.27.2 : > > http://ftp.gnome.org/pub/GNOME/sources/intltool/0.27/ If only it were that simple. As I said in my last mail, the problem was making intltool work with gettext-0.12.1 and recent automakes. This is not some feature that was removed between 0.27.2 and the latest CVS version (0.28). It was not there in the first place. I am, in fact, using intltool code that is not even in CVS yet (but some variation of it should get in without problems), because of this bugfix. See http://bugzilla.gnome.org/show_bug.cgi?id=127936 for the details and the patch. In case you are worried, there is no problems with using unreleased intltool versions in production code -- the required intltool scripts are shipped as part of the scrollkeeper tarball. Intltool was designed like that; people building from tarballs do not need intltool installed (the same as with automake and autoconf). One of the bugs that was fixed in the scrollkeeper-0.3.13 was removing a mistaken test that required tarball builders to have intltool installed externally. Cheers, Malcolm |
|
From: Christian M. <mar...@wa...> - 2003-12-05 13:37:15
|
Malcolm Tredinnick <ma...@co...> writes: > On Fri, 2003-12-05 at 19:55, Christian Marillat wrote: > [...] >> You have a problem with intltool because you are using an unreleased >> version 0.28. The latest intltool is 0.27.2 : >> >> http://ftp.gnome.org/pub/GNOME/sources/intltool/0.27/ > > If only it were that simple. As I said in my last mail, the problem was > making intltool work with gettext-0.12.1 and recent automakes. This is > not some feature that was removed between 0.27.2 and the latest CVS > version (0.28). It was not there in the first place. I've no problem here with gettext 0.12.1 and intltool 0.27.2 [...] > In case you are worried, there is no problems with using unreleased > intltool versions in production code -- the required intltool scripts > are shipped as part of the scrollkeeper tarball. Intltool was designed > like that; people building from tarballs do not need intltool installed > (the same as with automake and autoconf). One of the bugs that was fixed > in the scrollkeeper-0.3.13 was removing a mistaken test that required > tarball builders to have intltool installed externally. The problem is that intltool 0.28 need extra Perl module like XML::Parser ,---- | LC_ALL=C ../../intltool-merge ../../po scrollkeeper_cl.xml.in scrollkeeper_cl.xml -x -u -c ../../po/.intltool-merge-cache | You must have XML::Parser installed to run ../../intltool-merge `---- Where I can find this one ? ,---- | LC_ALL=C ../../intltool-merge ../../po scrollkeeper_cl.xml.in scrollkeeper_cl.xml -x -u -c ../../po/.intltool-merge-cache | The OrigTree module doesn't seem to be properly installed ../../intltool-merge `---- The OrigTree is part of XML::Parser but my version 2.34 doesn't have that. Christian |
|
From: Malcolm T. <ma...@co...> - 2003-12-05 13:48:24
|
On Sat, 2003-12-06 at 00:37, Christian Marillat wrote: > Malcolm Tredinnick <ma...@co...> writes: > > > On Fri, 2003-12-05 at 19:55, Christian Marillat wrote: > > [...] > >> You have a problem with intltool because you are using an unreleased > >> version 0.28. The latest intltool is 0.27.2 : > >> > >> http://ftp.gnome.org/pub/GNOME/sources/intltool/0.27/ > > > > If only it were that simple. As I said in my last mail, the problem was > > making intltool work with gettext-0.12.1 and recent automakes. This is > > not some feature that was removed between 0.27.2 and the latest CVS > > version (0.28). It was not there in the first place. > > I've no problem here with gettext 0.12.1 and intltool 0.27.2 Given that none of the intltool Makefile.in.in patches apply to gettext's Makefile.in.in, I find it hard to believe in "no problems" -- no error messages might be a possibility, though. Intltool tries to apply one patch to po/Makefile.in.in (the default one) and I think it says something like "three hunks failed" or whatever. [...] > The problem is that intltool 0.28 need extra Perl module like > XML::Parser > > ,---- > | LC_ALL=C ../../intltool-merge ../../po scrollkeeper_cl.xml.in scrollkeeper_cl.xml -x -u -c ../../po/.intltool-merge-cache > | You must have XML::Parser installed to run ../../intltool-merge > `---- > > Where I can find this one ? > > ,---- > | LC_ALL=C ../../intltool-merge ../../po scrollkeeper_cl.xml.in scrollkeeper_cl.xml -x -u -c ../../po/.intltool-merge-cache > | The OrigTree module doesn't seem to be properly installed ../../intltool-merge > `---- > > The OrigTree is part of XML::Parser but my version 2.34 doesn't have that. Yeah, that turns out to be a real bug. See another post to the list about this. Malcolm |