Derek Atkins <[EMAIL PROTECTED]> writes:
> Personally, I'd like to see the most amount of code reuse
> without code copying. Yes, QOF is external and eventually
> we should just use that. But I do NOT believe that we should
> rip out the core gnucash objects into their own source tree
> build.
Josh Sled <[EMAIL PROTECTED]> writes:
> I guess that's the misunderstanding... you keep calling the
> gnome-frontend "gnucash" and all the non-gui-related stuff
> "gnucash-common", as the debian packages are that way. I just don't
> conceptualize it that way, since the source isn't and I don't us
Neil Williams <[EMAIL PROTECTED]> writes:
>> Note that this might be
>> challenging to do "right", because lots of input verification
>> can be.. challenging.. to do in an abstract way.
>
> Is that the bulk of the "accounting logic" that we are considering for the
> intermediate library?
On Thursday 21 July 2005 9:59 pm, Derek Atkins wrote:
> Personally, I'd like to see the most amount of code reuse
> without code copying. Yes, QOF is external and eventually
> we should just use that. But I do NOT believe that we should
> rip out the core gnucash objects into their own source tre
I think there's a disconnect.. You're talking about packaging.
Josh is talking about source code. You're both right. :)
Personally, I'd like to see the most amount of code reuse
without code copying. Yes, QOF is external and eventually
we should just use that. But I do NOT believe that we sho
On Thursday 21 July 2005 3:11 pm, Josh Sled wrote:
> > The dependencies would sort out the rest, gnucash-common would be a
> > dependency of both, along with QOF. Installing either would draw in
> > gnucash-common and QOF anyway. The other dependencies (Gtk+ etc.) would
> > be gnucash-only.
>
> gnu
On Wed, 2005-07-20 at 20:41 +0100, Neil Williams wrote:
> On Wednesday 20 July 2005 6:19 pm, Josh Sled wrote:
> > On Tue, 2005-07-19 at 17:25 +0100, Neil Williams wrote:
> > > Whilst CashUtil is presently a separate tree, I have an eye on the
> > > changes that would be required to fold it into Gnu
Neil Williams <[EMAIL PROTECTED]> writes:
> On Tuesday 19 July 2005 5:25 pm, Neil Williams wrote:
>> Whilst CashUtil is presently a separate tree, I have an eye on the changes
>> that would be required to fold it into GnuCash whilst retaining a separate
>> package, in effect making a gnucash-commo
On Wednesday 20 July 2005 7:40 pm, Chris Shoemaker wrote:
> > Agreed. At some point (g2?) we should require current version of all
> > the autotools, and clean up the code to work properly with them.
>
> I also agree. I welcome Christian's effort to clean up the build
> system *in the g2 branch*.
On Wednesday 20 July 2005 6:19 pm, Josh Sled wrote:
> On Tue, 2005-07-19 at 17:25 +0100, Neil Williams wrote:
> > Whilst CashUtil is presently a separate tree, I have an eye on the
> > changes that would be required to fold it into GnuCash whilst retaining a
> > separate package, in effect making a
On Tue, 2005-07-19 at 17:25 +0100, Neil Williams wrote:
> Whilst CashUtil is presently a separate tree, I have an eye on the changes
> that would be required to fold it into GnuCash whilst retaining a separate
> package, in effect making a gnucash-common package that would go alongside
> QOF. T
I ran "libtoolize" from
> > that package. Maybe I didn't notice that ./autogen.sh does *not* run
> > libtoolize.
>
> ISTR that change was made about the time I joined the dev team three
> plus years ago.
>
> > In any case, then my removal of ltmain.sh
Phil Longstaff <[EMAIL PROTECTED]> writes:
> On July 19, 2005 10:04 am, Christian Stimming wrote:
>> No, that's not automake, instead it's the libtool package. I've recently
>> upgraded to suse9.3 which has libtool-1.5.14 and I ran "libtoolize" from
>
> I also just upgraded to 9.3, though I also h
Neil Williams <[EMAIL PROTECTED]> writes:
[snip]
> Maybe reorganising these would be useful too?
This is purely a debian packaging issue and should be taken off-list
and directly to the debian package maintainer. The gnucash team has
no ties directly to the debian package.
-derek
--
Der
On July 19, 2005 10:04 am, Christian Stimming wrote:
> No, that's not automake, instead it's the libtool package. I've recently
> upgraded to suse9.3 which has libtool-1.5.14 and I ran "libtoolize" from
I also just upgraded to 9.3, though I also had a problem on 9.1. I couldn't
run autogen.sh wi
On Tuesday 19 July 2005 5:25 pm, Neil Williams wrote:
> Whilst CashUtil is presently a separate tree, I have an eye on the changes
> that would be required to fold it into GnuCash whilst retaining a separate
> package, in effect making a gnucash-common package
OK, I realise there is a gnucash-comm
On Tuesday 19 July 2005 3:20 pm, David Hampton wrote:
> > By the way, we also have the file "acinclude.m4" in CVS. In current
> > automake/autoconf versions it is advised *against* that file, so at some
> > point in the future we should consider removing that file altogether.
>
> Agreed. At some p
autogen.sh does *not* run
> libtoolize.
ISTR that change was made about the time I joined the dev team three
plus years ago.
> In any case, then my removal of ltmain.sh was wrong and
> should be reverted. Sorry for that.
No big deal. I've broken the build a number of times.
toolize" from
that package. Maybe I didn't notice that ./autogen.sh does *not* run
libtoolize. In any case, then my removal of ltmain.sh was wrong and
should be reverted. Sorry for that.
By the way, we also have the file "acinclude.m4" in CVS. In current
automake/autocon
On Tue, 2005-07-19 at 11:29 +0200, Christian Stimming wrote:
> Did you run "autogen.sh" in the HEAD branch?
Yes, I always run autogen.sh.
> In my case this will
> install a system-dependent version of ltmain.sh, so I will always get
> this file marked as "modified" vs. the one in CVS.
Not wor
Did you run "autogen.sh" in the HEAD branch? In my case this will
install a system-dependent version of ltmain.sh, so I will always get
this file marked as "modified" vs. the one in CVS.
Okay, if this bothers too many people, my removal should be reverted.
In the g2-branch I already reverted t
Christian,
After picking up your last change I can no longer compile 1.8 or HEAD.
The automake program quits while processing configure.in with a
complaint that the ltmain.sh file is missing. I'm using automake 1.9.
Interestingly enough, I don't see the problem in the g2 branch.
David
22 matches
Mail list logo
