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 use
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. They
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?
I don't know.
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 GnuCash
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
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 tree
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
--
Derek
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 had a
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-common
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 that
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 working in
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/autoconf versions it is advised *against* that file, so at some
point in the future we
.
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.
By the way, we also have the file acinclude.m4 in CVS
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 point
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-common
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
16 matches
Mail list logo
