Removal of ltmain.sh

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Removal of ltmain.sh

David Hampton-2
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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Christian Stimming
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 removal due to unexpected
problems with my system's ltmain.sh.

Christian

David Hampton schrieb:

> 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
>
>
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

David Hampton-2
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 my case.

david@hampton-pc$ ../autogen.sh CC='ccache gcc'
   --prefix=/opt/gnucash/1.8 --enable-sql --enable-ofx
...
...
Running automake --gnu  ...
configure.in:64: required file `./ltmain.sh' not found
/usr/share/automake-1.9/am/tags.am: ctags was already defined in
condition !GNC_CTAGS_FILE, which is included in condition TRUE ...
Makefile.am:124: ... `ctags' previously defined here
**Error**: automake failed.
david@hampton-pc$

I'm running automake 1.9.5.  Perhaps there's been a recent change and
automake no longer copies libtool files to the local directory?  I just
ran strace on automake and it never tries to access
the /usr/local/libtool directory.

David


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Christian Stimming
David Hampton schrieb:

>>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 my case.
>
> I'm running automake 1.9.5.  Perhaps there's been a recent change and
> automake no longer copies libtool files to the local directory?  

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
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/autoconf versions it is advised *against* that file, so at some
point in the future we should consider removing that file altogether. At
the moment it probably masks some local macros that should be used.
Whatever. Okay, I won't touch these things again and will only silently
whine about locally changed files...

Christian

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

David Hampton-2
On Tue, 2005-07-19 at 16:04 +0200, 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
> 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 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. 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 (g2?) we should require current version of all
the autotools, and clean up the code to work properly with them.

David


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Neil Williams-2
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 (g2?) we should require current version of all
> the autotools, and clean up the code to work properly with them.

That would fit in with the API changes that were discussed in the CLI thread.

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. The GUI would add the Gtk interface, the CLI could use the same two
libraries without any GUI dependency. CashUtil would be installable with or
without gnucash - for those SSH users.

We'd have the gnucash GUI frontend, libqof1, gnucash-common and the
gnucash-cli frontend - cashutil. CashUtil would depend on QOF and
gnucash-common. This would make CashUtil a v.v.small unit - not much more
than the shell and a manpage but by working out how to do this separately, it
will be easier to move the UI logic into common.

1. Lots of makefile changes to redistribute existing code - e.g. the business
objects are needed in the CLI without any gncmodule binding. Updating the
autotools would be a pre-requisite for that.
2. Moving existing UI logic into another library, as discussed under the
language bindings thread.
3. Remove scheme *entirely* from both of these areas - possibly by defining
no-op hooks in the CLI where the GUI currently receives an event etc. Action
would then depend on what is linked to the library - scheme or not.

This is how the CLI could work with the existing XML backend and SQLite when
that arrives. What begins as a query CLI can be the CLI that people have
desired for so long.

gnucash-common would be a shared library that includes all the current objects
- including the business ones - a QOF-enabled GncCommodity (got ideas on
that), and the presently ill-defined UI logic that is currently only in the
GUI. As I move on with the CLI, I hope to identify precisely which bits of UI
are actually necessary for a genuine CLI implementation of GnuCash, growing
out of the current CashUtil.

Maybe something for GnuCash 2.2?

A new branch?

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Neil Williams-2
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 package (at least on Debian), although
it includes a lot of .h and test files so I don't really follow the reasoning
(seems more like a -devel).
http://packages.debian.org/unstable/gnome/gnucash-common

The main gnucash package contains all the libraries and compressed example
files,
usr/lib/gnucash/gnucash/libgw-engine.so.0
usr/share/doc/gnucash/examples/test2.xac

gnucash-common seems to contain:
usr/include/gnucash/Account.h
...
usr/share/gnucash/accounts/C/acctchrt_brokerage.gnucash-xea
...
usr/share/gnucash/doc/examples/Money95stocks_fr.qif

Maybe reorganising these would be useful too?

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

SuSE 9.3 (was Re: Removal of ltmain.sh)

Phil Longstaff-2
In reply to this post by Christian Stimming
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 without modifying macros/autogen.sh because GNOME2_PATH had
the value "/usr/local:/opt/gnome:/usr" and macros/autogen.sh wasn't set up to
handle a list of values.  I have locally modified macros/autogen.sh to add 3
-I flags with the 3 directories.  Is there a better solution?

Phil
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Debian Package (was Re: Removal of ltmain.sh)

Derek Atkins
In reply to this post by Neil Williams-2
Neil Williams <[hidden email]> 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 Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: SuSE 9.3 (was Re: Removal of ltmain.sh)

Derek Atkins
In reply to this post by Phil Longstaff-2
Phil Longstaff <[hidden email]> 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 problem on 9.1.  I couldn't
> run autogen.sh without modifying macros/autogen.sh because GNOME2_PATH had
> the value "/usr/local:/opt/gnome:/usr" and macros/autogen.sh wasn't set up to
> handle a list of values.  I have locally modified macros/autogen.sh to add 3
> -I flags with the 3 directories.  Is there a better solution?

Could you send in the patch?

-derek
--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Josh Sled
In reply to this post by Neil Williams-2
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. The GUI would add the Gtk interface, the CLI could use the same two
> libraries without any GUI dependency. CashUtil would be installable with or
> without gnucash - for those SSH users.

"Without gnucash"?

I think it should be...
   $ USE="cli" emerge gnucash    # => ./configure --enable-cli
...not...
   $ emerge gnucash-common gnucash-gtk gnucash-cli

(s/emerge/apt-get/ if you like...)


If it's part of the tree, then it is, and we can optionally build it.
What's the motivation for keeping it a seperate package?


> We'd have the gnucash GUI frontend, libqof1, gnucash-common and the
> gnucash-cli frontend - cashutil. CashUtil would depend on QOF and
> gnucash-common. This would make CashUtil a v.v.small unit - not much more
> than the shell and a manpage but by working out how to do this separately, it
> will be easier to move the UI logic into common.

Right now we have engine/ and app-utils/ and core-utils/ and
calculation/ and ...  I don't know if we need yet another layer of
gnucash-common (though cleaning up some of this legacy stuff would be
nice).  We definitely don't need a seperate *package* of gnucash-common.


> 1. Lots of makefile changes to redistribute existing code - e.g. the business
> objects are needed in the CLI without any gncmodule binding. Updating the
> autotools would be a pre-requisite for that.

Why would updated autotools be a pre-req for this?


> gnucash-common would be a shared library that includes all the current objects
> - including the business ones - a QOF-enabled GncCommodity (got ideas on
> that),

Hmmm.  It seems like we should preserve the ability to have optional
modules -- like the business subsystem -- *not* need to be part of a
core/common library.


> Maybe something for GnuCash 2.2?
>
> A new branch?

Maybe.  The volume of change and the timing is probably sufficient to
justify a 3.0, in which case this might be normal trunk development.  I
don't see, at this point, why it needs a branch.

...jsled

--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Chris Shoemaker
In reply to this post by David Hampton-2
On Tue, Jul 19, 2005 at 10:20:09AM -0400, David Hampton wrote:

> On Tue, 2005-07-19 at 16:04 +0200, 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
> > 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 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. 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 (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*.  Breaking the build and then fixing it is
better than living with a quirky build system.  So, is anybody willing
to fix this the "right way"?  I'm willing to test.  :)

-chris

>
> David
>
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Neil Williams-2
In reply to this post by Josh Sled
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 gnucash-common package that would go
> > alongside QOF. The GUI would add the Gtk interface, the CLI could use the
> > same two libraries without any GUI dependency. CashUtil would be
> > installable with or without gnucash - for those SSH users.
>
> "Without gnucash"?

Yes. For those situations where you want to be able to access the data file
without a GUI environment being available. It's far easier to scp a 2Mb data
file than to live with X over a slow network connection.
:-))

I certainly want to be able to install cashutil on non-GUI systems. Also on
non-X systems and remote X systems.

> I think it should be...
>    $ USE="cli" emerge gnucash    # => ./configure --enable-cli

?? I don't know emerge but that won't work with apt-get.

> ...not...
>    $ emerge gnucash-common gnucash-gtk gnucash-cli
>
> (s/emerge/apt-get/ if you like...)

But it would be:
# apt-get install gnucash cashutil

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.

Users would only install whichever they needed.

> If it's part of the tree, then it is, and we can optionally build it.
> What's the motivation for keeping it a seperate package?

Confusion here.

Project: separate source tree, separate CVS, separate support.
Package: decision by distribution maintainers on how to make their
dependencies work.

1. It is a separate project currently because it cannot yet deal with the
current backend.

2. Even if it is part of the gnucash CVS tree (which it would be if it does
get to deal with the current backend), it can still be a separate package at
the user end (apt-get).

> > We'd have the gnucash GUI frontend, libqof1, gnucash-common and the
> > gnucash-cli frontend - cashutil. CashUtil would depend on QOF and
> > gnucash-common. This would make CashUtil a v.v.small unit - not much more
> > than the shell and a manpage but by working out how to do this
> > separately, it will be easier to move the UI logic into common.
>
> Right now we have engine/ and app-utils/ and core-utils/ and
> calculation/ and ...

You're looking at the source tree, I'm looking at the apt-get package list.

> I don't know if we need yet another layer of
> gnucash-common (though cleaning up some of this legacy stuff would be
> nice).  We definitely don't need a seperate *package* of gnucash-common.

engine goes into QOF.
app-utils and core-utils probably into gnucash.
the objects and business-core go into gnucash-common.

It's not straightforward and I won't have a definite answer on what goes where
until the CLI is more advanced.

But, as Derek pointed out, this is all maintainer stuff. I'll be discussing it
off-list with the Debian maintainer (as gnucash-common DOES already exist).

None of this needs concern the source tree, only the Makefiles. There might be
a few files moving directory but that's already being done in G2.

Let me get the CLI working and then I'll come back with a definite idea of
what needs to go where.

> > 1. Lots of makefile changes to redistribute existing code - e.g. the
> > business objects are needed in the CLI without any gncmodule binding.
> > Updating the autotools would be a pre-requisite for that.
>
> Why would updated autotools be a pre-req for this?

Because it'll make it easier to reorganise the current library make
instructions so that object source files currently in the business module
(for example) can be directed into an existing library making that suitable
for linking against the CLI.

e.g. I need Account.c and gncInvoice.c in the same shared library (or at least
loadable in two libraries that do not rely on any scheme). Those would be
packaged at the user end as part of gnucash-common.

Currently, I'm working with copies from the current tree.

> > gnucash-common would be a shared library that includes all the current
> > objects - including the business ones - a QOF-enabled GncCommodity (got
> > ideas on that),
>
> Hmmm.  It seems like we should preserve the ability to have optional
> modules -- like the business subsystem -- *not* need to be part of a
> core/common library.

But business isn't separate in the real user world. It's a module but without
recompiling gnucash, you can't *not* load it. The CLI needs the business
objects and cannot work with the old gnc-module loading system so something
does need to change.

I'm OK either way - if I copy the objects into a new tree then I'll have the
same situation as now with QOF, with the advantage that the object files
change less frequently!

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Neil Williams-2
In reply to this post by Chris Shoemaker
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*.  Breaking the build and then fixing it is
> better than living with a quirky build system.  So, is anybody willing
> to fix this the "right way"?  I'm willing to test.  :)

I hope to do some of the clean-up as a result of the CLI but I can't say how
long it'll take.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Thomas Bushnell BSG
In reply to this post by Neil Williams-2
Neil Williams <[hidden email]> 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 package
>
> OK, I realise there is a gnucash-common package (at least on
> Debian), although it includes a lot of .h and test files so I don't
> really follow the reasoning (seems more like a -devel).
> http://packages.debian.org/unstable/gnome/gnucash-common

It is standard Debian procedure to try and separate out
architecture-independent parts of a package so that we can save space
in the archive.  So gnucash-common has the bits that are the same on
every architecture (and thus don't need to be duplicated).

gnucash-common is 2.8 MB right now, thus saving something like 40MB by
not duplicating it for each architecture.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Josh Sled
In reply to this post by Neil Williams-2
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 whilst retaining a
> > > separate package, in effect making a gnucash-common package that would go
> > > alongside QOF. The GUI would add the Gtk interface, the CLI could use the
> > > same two libraries without any GUI dependency. CashUtil would be
> > > installable with or without gnucash - for those SSH users.
> >
> > "Without gnucash"?
>
> Yes. For those situations where you want to be able to access the data file
> without a GUI environment being available. It's far easier to scp a 2Mb data
> file than to live with X over a slow network connection.

Oh.  "Without the gnucash gtk-gui".


> > I think it should be...
> >    $ USE="cli" emerge gnucash    # => ./configure --enable-cli
>
> ?? I don't know emerge but that won't work with apt-get.

Okay.  I understand apt-get does this via multiple packages rather than
attributes (gentoo: "use-flags") on a single package.


> But it would be:
> # apt-get install gnucash cashutil
>
> 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.

gnucash != gnucash-gnome-frontend.

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
debian.


> > I don't know if we need yet another layer of
> > gnucash-common (though cleaning up some of this legacy stuff would be
> > nice).  We definitely don't need a seperate *package* of gnucash-common.
>
> engine goes into QOF.
> app-utils and core-utils probably into gnucash.
> the objects and business-core go into gnucash-common.

Maybe mis-reading you, but I don't see how the gnucash engine concepts
go into the QOF package...?  I see [all in src/]:

* {engine,{app,core}-utils,register/core,reports/core,...} => gnucash

* business => gnucash-business

* {business,register,report}/gnome, gnome{,-utils} => gnucash-gnome

* cashutil => cashutil
    [or maybe...]
* business/cli, register/cli, cli-utils => gnucash-cli  ??


> It's not straightforward and I won't have a definite answer on what goes where
> until the CLI is more advanced.

Hmm.  I guess you could look at the existing front-end and extrapolate
out what another would look like...


> But business isn't separate in the real user world. It's a module but without
> recompiling gnucash, you can't *not* load it. The CLI needs the business
> objects and cannot work with the old gnc-module loading system so something
> does need to change.

The gnc-module loading system, I believe.  But that's a good point.
Things are structured so that is the case, though... maybe not fully,
but most of the way.  We should continue along that path, I think.

...jsled

--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Neil Williams-2
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.
>
> gnucash != gnucash-gnome-frontend.

OK, I tend to consider the CLI as just CashUtil, then there's QOF (which I'd
like GnuCash to use as a separate library by then) and if CashUtil is going
to use all the logic inherent in the current GnuCash G2, as well as the
current backend (+/- replacement), then the abstraction of the current UI
logic into it's own API that is shared with CashUtil is going to mean that
the GUI will be a front-end for the shared libraries behind it.

That is nowhere near where it is now, it's how I'd like it to be in the
future. However, it is not a huge departure - GnuCash already uses a host of
internal libraries. All I'm suggesting is a reorganisation of those libraries
to put the financial logic alongside the objects in a library that can be
used by the CLI. If that works, then the CLI can be folded into the GnuCash
source tree.

The CLI and the gnucash-gtk front end would each be built against QOF and
another library that contains:
1. All existing objects, business or otherwise.
2. Abstracted logic from what is currently the UI in a form that both programs
can use.
3. The current gnucash xml v2 backend, including business object handling.

Each would have their own code to express:
1. Their own UI, Gtk for one, CLI for the other.
2. Suitable error message handling according to the UI, dialogs vs stderr.
3. The GUI would keep all the reports and tree model.

Once I've been able to demonstrate to myself that this could work, only then
would I consider folding CashUtil into the GnuCash source tree - it would be
natural then to share the new library that would be created by the fold as
well as share the source code. Then I would finally be free from manually
copying source files between projects!
:-)

> 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.

The gnucash-common in Debian, as Thomas pointed out, is an architecture thing
- not a UI/logic thing. It actually has nothing to do with the source tree
and everything to do with i386 vs SPARC etc.

I thought of gnucash-common from a source perspective. It may not turn out
that way. It may turn out to be a financial logic library, internal to
GnuCash and CashUtil, with it's own API.

> I just don't
> conceptualize it that way, since the source isn't

It's a lot of work to reconfigure the source to allow this to happen. It's
largely a case of removing all '#include's that reference private headers and
replacing the calls with an API (leaving function either unchanged or
enhanced) and switching files/functions around to make it easier to modify
the Makefile rules to build the same code into differently structured
libraries that better suit the logical divide between GUI and CLI.

Building the CLI as a separate project will allow me to identify those
functions that are necessary for the proper logic in dealing with current
GnuCash data in a CLI environment. Initially, the CLI will have limited
financial logic and this is a weakness that is likely to confuse users and
restrict the use of the CLI. Only by abstracting the logic from what are
currently UI source files can I incorporate that logic into a CLI that can be
built without a GUI environment.

> and I don't use
> debian.

:-)

> > > I don't know if we need yet another layer of
> > > gnucash-common (though cleaning up some of this legacy stuff would be
> > > nice).  We definitely don't need a seperate *package* of
> > > gnucash-common.
> >
> > engine goes into QOF.
> > app-utils and core-utils probably into gnucash.
> > the objects and business-core go into gnucash-common.
>
> Maybe mis-reading you, but I don't see how the gnucash engine concepts
> go into the QOF package...?  I see [all in src/]:
The gnucash engine IS QOF and vice versa. Each qof_ function is part of
libqof1 and gnucash can run using QOF as an external shared library. There
are no qof* functions outside QOF. Take a look at the source of QOF and
you'll find all the files are common. When GnuCash eventually uses QOF as an
external library, only the QOF objects (like Account and gncInvoice) need to
remain in gnucash. CashUtil abstracts this further by putting those objects
into a common library along with other ancillary logic sources that are
currently spread over the entire tree.

> * {engine,{app,core}-utils,register/core,reports/core,...} => gnucash

No. Nearly everything src/engine/qof* and src/engine/gnc* is QOF. Gnucash can
run quite well using the libqof1 library to provide these. In some ways, it
already does as the engine code is built into an internal library. By making
that internal library interchangeable with libqof1, gnucash can run without
most of src/engine.

> * business => gnucash-business

Currently, but a lot of the business logic will be needed in the CLI and that
is why I'm currently copying 99% of business-core/ into cashutil/src/ -
business-gnome and business-report remain GUI. Other files remain to be
identified.

business-core/file will also need to live in the shared library if the current
GnuCash v2 XML backend is to be shared with the CLI.

It may turn out that this isn't one but a set of libraries. I don't mind. What
I do want is an API that allows the user to interact with GnuCash data using
GnuCash objects via the CLI and all without the GUI being required. And
without impinging on any of the current GUI functionality - rather, I hope to
enhance it by providing a clearer API.

> * {business,register,report}/gnome, gnome{,-utils} => gnucash-gnome

Reports, utils, gnome - yes, gnucash GUI. There may be some UI logic in other
directories that can be abstracted but that's a way off yet.

> * cashutil => cashutil
>     [or maybe...]
> * business/cli, register/cli, cli-utils => gnucash-cli  ??

That's if CashUtil does come into the GnuCash tree. It's currently separate.
If this all turns out to be pie-in-the-sky then CashUtil can continue as a
separate project and I'll still be copying source files between trees.
:-(

Personally, I'd go for src/cli - containing only four source files:
qof-main.c|h which contain the generic QOF CLI interactive shell, init
functions and error messages that will also be found in PilotQOF etc., and
cashutil.c|h that contain the specific code to load the invoice, account,
customer etc. objects and ancillary logic from the financial logic library.
The usual manpage subdirectory would be beneath src/cli as well as a test/
subdir.

> > It's not straightforward and I won't have a definite answer on what goes
> > where until the CLI is more advanced.
>
> Hmm.  I guess you could look at the existing front-end and extrapolate
> out what another would look like...

I think some of pilot-link is a better example of the final CLI - I'm using a
lot of their menu and shell code. Unlike pilot-link, the CLI will be single
program, not a collection. With the vast majority of the code being QOF and
the shared financial logic library, CashUtil itself will likely be tiny
anyway.

> > But business isn't separate in the real user world. It's a module but
> > without recompiling gnucash, you can't *not* load it. The CLI needs the
> > business objects and cannot work with the old gnc-module loading system
> > so something does need to change.
>
> The gnc-module loading system, I believe.  But that's a good point.
> Things are structured so that is the case, though... maybe not fully,
> but most of the way.  We should continue along that path, I think.

Hang on, continue using gnc-module or continue moving to a non-Scheme library
approach?

IMHO, if we want to reduce the amount of Scheme in the engine and related
code, the business gnc-module needs to be overhauled. If the business object
files like gncInvoice.c remain in a Scheme loaded module, I'd rather keep
copying files around.
:-(

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Derek Atkins
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 should
rip out the core gnucash objects into their own source tree
build.  They can be their own binary package, but the source
should be in one and only one tarball.

- I'd like to see Cashutil folded into the gnucash source tree.
- I'd like to see the gnucash source tree "fixed" to handle
  cashutil.  This may require moving libraries around a bit,
  or it might not.
- I'd like to see the "accounting logic" moved out of the GUI
  and into an intermediate library.  However this should still
  be part of the gnucash source tree.  Note that this might be
  challenging to do "right", because lots of input verification
  can be.. challenging..  to do in an abstract way.
- I'd like to see the packaging (RPMS, .debs, etc) fixed to
  provide multiple packages so someone could install cashutil
  without installing gnucash-gtk.

I think this would solve everyone's issue.

In the short term, is there really a problem installing cashutil and
gnucash simultaneously from the same source tree?

-derek

Neil Williams <[hidden email]> writes:

> 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.
>>
>> gnucash != gnucash-gnome-frontend.
>
> OK, I tend to consider the CLI as just CashUtil, then there's QOF (which I'd
> like GnuCash to use as a separate library by then) and if CashUtil is going
> to use all the logic inherent in the current GnuCash G2, as well as the
> current backend (+/- replacement), then the abstraction of the current UI
> logic into it's own API that is shared with CashUtil is going to mean that
> the GUI will be a front-end for the shared libraries behind it.
>
> That is nowhere near where it is now, it's how I'd like it to be in the
> future. However, it is not a huge departure - GnuCash already uses a host of
> internal libraries. All I'm suggesting is a reorganisation of those libraries
> to put the financial logic alongside the objects in a library that can be
> used by the CLI. If that works, then the CLI can be folded into the GnuCash
> source tree.
>
> The CLI and the gnucash-gtk front end would each be built against QOF and
> another library that contains:
> 1. All existing objects, business or otherwise.
> 2. Abstracted logic from what is currently the UI in a form that both programs
> can use.
> 3. The current gnucash xml v2 backend, including business object handling.
>
> Each would have their own code to express:
> 1. Their own UI, Gtk for one, CLI for the other.
> 2. Suitable error message handling according to the UI, dialogs vs stderr.
> 3. The GUI would keep all the reports and tree model.
>
> Once I've been able to demonstrate to myself that this could work, only then
> would I consider folding CashUtil into the GnuCash source tree - it would be
> natural then to share the new library that would be created by the fold as
> well as share the source code. Then I would finally be free from manually
> copying source files between projects!
> :-)
>
>> 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.
>
> The gnucash-common in Debian, as Thomas pointed out, is an architecture thing
> - not a UI/logic thing. It actually has nothing to do with the source tree
> and everything to do with i386 vs SPARC etc.
>
> I thought of gnucash-common from a source perspective. It may not turn out
> that way. It may turn out to be a financial logic library, internal to
> GnuCash and CashUtil, with it's own API.
>
>> I just don't
>> conceptualize it that way, since the source isn't
>
> It's a lot of work to reconfigure the source to allow this to happen. It's
> largely a case of removing all '#include's that reference private headers and
> replacing the calls with an API (leaving function either unchanged or
> enhanced) and switching files/functions around to make it easier to modify
> the Makefile rules to build the same code into differently structured
> libraries that better suit the logical divide between GUI and CLI.
>
> Building the CLI as a separate project will allow me to identify those
> functions that are necessary for the proper logic in dealing with current
> GnuCash data in a CLI environment. Initially, the CLI will have limited
> financial logic and this is a weakness that is likely to confuse users and
> restrict the use of the CLI. Only by abstracting the logic from what are
> currently UI source files can I incorporate that logic into a CLI that can be
> built without a GUI environment.
>
>> and I don't use
>> debian.
>
> :-)
>
>> > > I don't know if we need yet another layer of
>> > > gnucash-common (though cleaning up some of this legacy stuff would be
>> > > nice).  We definitely don't need a seperate *package* of
>> > > gnucash-common.
>> >
>> > engine goes into QOF.
>> > app-utils and core-utils probably into gnucash.
>> > the objects and business-core go into gnucash-common.
>>
>> Maybe mis-reading you, but I don't see how the gnucash engine concepts
>> go into the QOF package...?  I see [all in src/]:
>
> The gnucash engine IS QOF and vice versa. Each qof_ function is part of
> libqof1 and gnucash can run using QOF as an external shared library. There
> are no qof* functions outside QOF. Take a look at the source of QOF and
> you'll find all the files are common. When GnuCash eventually uses QOF as an
> external library, only the QOF objects (like Account and gncInvoice) need to
> remain in gnucash. CashUtil abstracts this further by putting those objects
> into a common library along with other ancillary logic sources that are
> currently spread over the entire tree.
>
>> * {engine,{app,core}-utils,register/core,reports/core,...} => gnucash
>
> No. Nearly everything src/engine/qof* and src/engine/gnc* is QOF. Gnucash can
> run quite well using the libqof1 library to provide these. In some ways, it
> already does as the engine code is built into an internal library. By making
> that internal library interchangeable with libqof1, gnucash can run without
> most of src/engine.
>
>> * business => gnucash-business
>
> Currently, but a lot of the business logic will be needed in the CLI and that
> is why I'm currently copying 99% of business-core/ into cashutil/src/ -
> business-gnome and business-report remain GUI. Other files remain to be
> identified.
>
> business-core/file will also need to live in the shared library if the current
> GnuCash v2 XML backend is to be shared with the CLI.
>
> It may turn out that this isn't one but a set of libraries. I don't mind. What
> I do want is an API that allows the user to interact with GnuCash data using
> GnuCash objects via the CLI and all without the GUI being required. And
> without impinging on any of the current GUI functionality - rather, I hope to
> enhance it by providing a clearer API.
>
>> * {business,register,report}/gnome, gnome{,-utils} => gnucash-gnome
>
> Reports, utils, gnome - yes, gnucash GUI. There may be some UI logic in other
> directories that can be abstracted but that's a way off yet.
>
>> * cashutil => cashutil
>>     [or maybe...]
>> * business/cli, register/cli, cli-utils => gnucash-cli  ??
>
> That's if CashUtil does come into the GnuCash tree. It's currently separate.
> If this all turns out to be pie-in-the-sky then CashUtil can continue as a
> separate project and I'll still be copying source files between trees.
> :-(
>
> Personally, I'd go for src/cli - containing only four source files:
> qof-main.c|h which contain the generic QOF CLI interactive shell, init
> functions and error messages that will also be found in PilotQOF etc., and
> cashutil.c|h that contain the specific code to load the invoice, account,
> customer etc. objects and ancillary logic from the financial logic library.
> The usual manpage subdirectory would be beneath src/cli as well as a test/
> subdir.
>
>> > It's not straightforward and I won't have a definite answer on what goes
>> > where until the CLI is more advanced.
>>
>> Hmm.  I guess you could look at the existing front-end and extrapolate
>> out what another would look like...
>
> I think some of pilot-link is a better example of the final CLI - I'm using a
> lot of their menu and shell code. Unlike pilot-link, the CLI will be single
> program, not a collection. With the vast majority of the code being QOF and
> the shared financial logic library, CashUtil itself will likely be tiny
> anyway.
>
>> > But business isn't separate in the real user world. It's a module but
>> > without recompiling gnucash, you can't *not* load it. The CLI needs the
>> > business objects and cannot work with the old gnc-module loading system
>> > so something does need to change.
>>
>> The gnc-module loading system, I believe.  But that's a good point.
>> Things are structured so that is the case, though... maybe not fully,
>> but most of the way.  We should continue along that path, I think.
>
> Hang on, continue using gnc-module or continue moving to a non-Scheme library
> approach?
>
> IMHO, if we want to reduce the amount of Scheme in the engine and related
> code, the business gnc-module needs to be overhauled. If the business object
> files like gncInvoice.c remain in a Scheme loaded module, I'd rather keep
> copying files around.
> :-(
>
> --
>
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Neil Williams-2
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
> build.

Currently, I'm doing that only to create a test bed. I'm thinking more and
more that this is a temporary stage and the goal should be full inclusion in
the gnucash source tree.

> They can be their own binary package, but the source
> should be in one and only one tarball.

Agreed.

> - I'd like to see Cashutil folded into the gnucash source tree.
> - I'd like to see the gnucash source tree "fixed" to handle
>   cashutil.  This may require moving libraries around a bit,
>   or it might not.
> - I'd like to see the "accounting logic" moved out of the GUI
>   and into an intermediate library.  However this should still
>   be part of the gnucash source tree.

Agreed - I'll work from the temporary build to identify the areas that need to
be in that library.

>   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'd like to see the packaging (RPMS, .debs, etc) fixed to
>   provide multiple packages so someone could install cashutil
>   without installing gnucash-gtk.

> I think this would solve everyone's issue.

Definitely.

> In the short term, is there really a problem installing cashutil and
> gnucash simultaneously from the same source tree?

I don't know is the honest answer. I'm working from this direction because it
suits my needs for a testbed application for the QSF and QOF_TYPE_COLLECT /
CHOICE code. I need to concentrate on that use of it initially to make the
new code ready for G2.

Once I've debugged QSF, then I'll look at how the CLI fits into the gnucash
source tree and I'll have a list of files and functions that the CLI would
benefit from being able to access via the intermediate library.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removal of ltmain.sh

Derek Atkins
Neil Williams <[hidden email]> 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.  I'm not exactly sure off the top of my head what kind
of logic needs to bet abstracted.  I know that "input verification" is
definitely some of it.

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
12