"
> >>
> >> overwrite the variable?? In the original you had:
> >> set DSPF -python -Wall -Werror $(SWIG_ARGS)
> >> if (swig_version < 4.1)
> >>
> >> set DSPF $(SWIG_ARGS) -py3
> >>
> >> Wouldn't this ov
>> set DSPF -python -Wall -Werror $(SWIG_ARGS)
>> if (swig_version < 4.1)
>> set DSPF $(SWIG_ARGS) -py3
>>
>> Wouldn't this override DSPF if swig is < 4.1, getting rid of -python -Wall
>> -Werror? That would mean that on systems with swig <
4.1)
> set DSPF $(SWIG_ARGS) -py3
>
> Wouldn't this override DSPF if swig is < 4.1, getting rid of -python -Wall
> -Werror? That would mean that on systems with swig < 4.1, it would not be
> running with -Wall -Werror, but with your new change it WOULD -- causing
>
I'm going to throw some ideas out there, but... doesn't the "set"
overwrite the variable?? In the original you had:
set DSPF -python -Wall -Werror $(SWIG_ARGS)
if (swig_version < 4.1)
set DSPF $(SWIG_ARGS) -py3
Wouldn't this override DSPF if swig is < 4.
m https://github.com/Gnucash/gnucash/commit/cbf89a73 (commit)
>
>
>
> commit b9eb550b9a9a2ff0a5e926debb1bee5a073a5319
> Author: Geert Janssens
> Date: Thu Feb 22 11:13:59 2024 +0100
>
> Do a better job of including the -py3 option only for swig 4.1
>
> The pre
85c
> >>> (commit)
> >>>
> >>> from https://github.com/Gnucash/gnucash/commit/4e9990dd (commit)
> >>>
> >>> commit 659f785cb81396412e503b4d8f5fe22ceb3f39df
> >>> Author: John Ralls
> >>> Date: Fri May 15 12:37:2
>> Author: John Ralls
>>> Date: Fri May 15 12:37:24 2020 -0700
>>>
>>> Bug 797750 - SIGSEV in swig-engine.c
>>
>> Frank,
>>
>> Did you push intentionally to the github repo ? As far as I know we don't
>> usually push fea
ash/commit/4e9990dd (commit)
> >
> > commit 659f785cb81396412e503b4d8f5fe22ceb3f39df
> > Author: John Ralls
> > Date: Fri May 15 12:37:24 2020 -0700
> >
> > Bug 797750 - SIGSEV in swig-engine.c
>
> Frank,
>
> Did you push intentionally to the gi
> Author: John Ralls
> Date: Fri May 15 12:37:24 2020 -0700
>
> Bug 797750 - SIGSEV in swig-engine.c
>
>
Frank,
Did you push intentionally to the github repo ? As far as I know we don't
usually push feature
branches there :)
Regards,
Geert
_
Hello,
I've picked my work from 2018 up again and made the QofSessionImpl c++
swig wrapping a PR (https://github.com/Gnucash/gnucash/pull/732).
This doesn't need to be final. It can be a basis for discussion of
wrapping the c++ parts. As far as I have understood there is a process
> On May 21, 2019, at 6:08 AM, Derek Atkins wrote:
>
> John Ralls writes:
>
>>> On May 20, 2019, at 6:02 AM, Derek Atkins wrote:
>>>
>>> Does the tarfile not create a tree gnucash_XX (where XX is the
>>> git hash of the tarball)?
>>>
>>> I guess there is no way to disable this "fe
John Ralls writes:
>> On May 20, 2019, at 6:02 AM, Derek Atkins wrote:
>>
>> Does the tarfile not create a tree gnucash_XX (where XX is the
>> git hash of the tarball)?
>>
>> I guess there is no way to disable this "feature" of github?
>
> Nope. It just creates a zip file "gnucash-maint
> On May 20, 2019, at 6:02 AM, Derek Atkins wrote:
>
> Geert Janssens writes:
>
>>> Another alternative is just print "GITHUB RELEASE XXX" and grab XXX from
>>> the top-level directory name?
>>
>> The top-level directory name can be anything and not related to git or github
>> at all. It de
Geert Janssens writes:
>> Another alternative is just print "GITHUB RELEASE XXX" and grab XXX from
>> the top-level directory name?
>
> The top-level directory name can be anything and not related to git or github
> at all. It depends on where a user extracts the zip file.
Does the tarfile not c
e. My objective is to find a way to get "almost-always-swig"
> without changing the requirements for building release tarballs so that we
> don't have to wait until 4.x, at which point we can take away the
> "almost-always".
Ok, that's a useful paradigm
nt ecosystem.
>
> *I* like to build in source!
>
> Or, more technically, I use lndir to create a symlink tree build dir and
> then build from there. So *technically* srcdir = .
>
I believe that would confuse the build system if we adopt John's suggestion of
testing for the
ing in the source tree.
However the issue I
mentioned wouldn't trigger here either as flatpak always forces a fresh source
tree for each new
build, so John's suggestion of testing for the presence of swig-foo.c should
still work even there.
Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
On 5/16/19 8:08 AM, Derek Atkins wrote:
> Geert Janssens writes:
>
>> For starters despite our advice several people still prefer to build in
>> source. It appears this notion of a separate build directory is not
>> ingrained
>> deeply into the development ecosystem.
> *I* like to build in sour
create a symlink tree build dir and
then build from there. So *technically* srcdir = .
> Secondly it introduces a different build behavior between building in-source
> or out-of-tree. The former would run swig once and then never again while the
> latter (ideally) runs swig wheneve
ease or on master ? I'm inclined to go for the latter as not to
>>> trip up too many distro packagers in the middle of a stable series.
>>
>> I agree that we don't want to mess with the release build requirements
>> during a stable series, but why not continue to p
e middle of a stable series.
>
> I agree that we don't want to mess with the release build requirements
> during a stable series, but why not continue to pre-swig the release
> tarballs? We can distinguish between swig-foo.c being in srcdir or not to
> decide whether swig
to introduce this ? Would you do it for the next
> stable release or on master ? I'm inclined to go for the latter as not to
> trip
> up too many distro packagers in the middle of a stable series.
I agree that we don't want to mess with the release build requirements during a
stable
Op woensdag 15 mei 2019 15:43:43 CEST schreef John Ralls:
> OK, that all sounds reasonable.
>
> Regards,
> John Ralls
Glad you agree.
Remaining question is when to introduce this ? Would you do it for the next
stable release or on master ? I'm inclined to go for the latter as not to trip
up to
retty much no one else has done
anything
serious with them.
Hopefully Mark is still around on the list to clarify.
In other words, if anyone knows, it’s you!
True :)
Just to add some more confusion, there’s now a C++ class GncNumeric
that
handles the actual implementation of many of the gnc_nume
us with them.
Hopefully Mark is still around on the list to clarify.
In other words, if anyone knows, it’s you!
True :)
Just to add some more confusion, there’s now a C++ class GncNumeric
that
handles the actual implementation of many of the gnc_numeric.*
functions. I
believe that SWIG can’t see it,
Christoph Holtermann wrote
> I'm willing to now and then do something for the python bindings. I
> don't feel like an expert. But surely I'd like to talk and think things
> through
> about them. Maybe someone is interested. I saw that there were some people
> asking questions about the bindings
nucash/commit/2f861bc2 (commit)
>>
>>
>>
>> commit 22dd716b58a6a9c424a71268f78af37b972ab23b
>> Author: John Ralls
>> Date: Fri Aug 10 12:57:46 2018 -0700
>>
>>Set the SWIG minimum version to 2.0.11 now that we require Guile-2.0.
>>
>&
2ab23b
> Author: John Ralls
> Date: Fri Aug 10 12:57:46 2018 -0700
>
> Set the SWIG minimum version to 2.0.11 now that we require Guile-2.0.
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index f5d372e..42a23b6 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
us with them.
Hopefully Mark is still around on the list to clarify.
In other words, if anyone knows, it’s you!
True :)
Just to add some more confusion, there’s now a C++ class GncNumeric
that
handles the actual implementation of many of the gnc_numeric.*
functions. I
believe that SWIG can’t see it,
ev, he just
>>> got 16 patches committed between 2007 and 2012, 10 of which touched the
>>> python bindings. Your history with them is almost as long as his--in fact
>>> you have *12* commits--and pretty much no one else has done anything
>>> serious with them.
>
f anyone knows, it’s you!
True :)
Just to add some more confusion, there’s now a C++ class GncNumeric
that
handles the actual implementation of many of the gnc_numeric.*
functions. I
believe that SWIG can’t see it, only the C wrapper functions are
exposed to
SWIG.
It would be a very useful experi
Op maandag 6 augustus 2018 11:35:43 CEST schreef c.holterm...@gmx.de:
> Then you speak of c++ GncNumeric. As I understand you are moving the
> source
> from c to c++. So the python bindings need to reflect that. That sounds
> like
> another piece of work. Is there imminent need for change there ? C
can access the SwigObject through
its instance property.
The other way round seems not as simple.
My method __gncnumeric__str__ overwrites the __str__ method using
add_method.
In this method self points to the swig object. I cannot use the
methods of GncNumeric as
it is the layer of the wrappin
pefully Mark is still around on the list to clarify.
> In other words, if anyone knows, it’s you!
True :)
>
> Just to add some more confusion, there’s now a C++ class GncNumeric that
> handles the actual implementation of many of the gnc_numeric.* functions. I
> believe that SWIG can’t
> When I have the GncNumeric object I can access the SwigObject through its
> instance property.
> The other way round seems not as simple.
>
> My method __gncnumeric__str__ overwrites the __str__ method using add_method.
>
> In this method self points to the swig obje
not as simple.
My method __gncnumeric__str__ overwrites the __str__ method using
add_method.
In this method self points to the swig object. I cannot use the methods
of GncNumeric as
it is the layer of the wrapping object.
To access these methods I used to instantiate a
GncNumeric(instance=self) as a temporary
ding from an scm managed directory... no
>> [ 59s] checking for ./src/swig-runtime.h... no
>> [ 59s] configure: error:
>> [ 59s]
>> [ 59s] It looks like you are NOT building from Subversion, svk, git or bzr
>> [ 59s] but I cannot find swig-runtime.h. Check your
> On Aug 4, 2016, at 3:01 PM, Christian wrote:
>
> Hi,
>
> trying to build (update my gnucash RPM from 2.6.12 to 2.6.13) but
> running into this problem:
>
> [ 59s] checking if building from an scm managed directory... no
> [ 59s] checking for ./src/swi
Hi,
Christian writes:
> Hi,
>
> trying to build (update my gnucash RPM from 2.6.12 to 2.6.13) but
> running into this problem:
>
> [ 59s] checking if building from an scm managed directory... no
> [ 59s] checking for ./src/swig-runtime.h... no
> [ 59s] con
Hi,
trying to build (update my gnucash RPM from 2.6.12 to 2.6.13) but
running into this problem:
[ 59s] checking if building from an scm managed directory... no
[ 59s] checking for ./src/swig-runtime.h... no
[ 59s] configure: error:
[ 59s]
[ 59s] It looks like you are NOT building from
ot;make dist" from any random commit
> > and build from the resulting tarball. But no, you cannot just tar
> > up a random commit and build it.
>
> Hmm, valid point. So in addition to rejiggering the "do we need swig"
> logic we should also change the versioning
> random commit and build it.
Hmm, valid point. So in addition to rejiggering the "do we need swig" logic we
should also change the versioning logic with VCS builds so that the version
that goes on the splash screen and Help>About is the output of `git describe`.
I suppose to be pe
y is there (still) a good reason to avoid on the fly swig code
>> generation for a (release) tarball build ?
>
> I wasn’t actually around for it, but I suspect that the reason was to
> avoid having SWIG as a dependency for building release tarballs. I
> think that that’s still wort
; What is the original reason it was implemented this way ? Or put
> >>> differently is there (still) a good reason to avoid on the fly
> >>> swig
> >>> code generation for a (release) tarball build ?
> >>
> >> I wasn’t actually around for it, bu
t; differently is there (still) a good reason to avoid on the fly swig
>>> code generation for a (release) tarball build ?
>>
>> I wasn’t actually around for it, but I suspect that the reason was to
>> avoid having SWIG as a dependency for building release tarballs. I
>>
On Saturday 28 March 2015 12:56:10 John Ralls wrote:
> > On Mar 28, 2015, at 3:16 AM, Geert Janssens
> > wrote:
> > What is the original reason it was implemented this way ? Or put
> > differently is there (still) a good reason to avoid on the fly swig
> > code gene
> On Mar 28, 2015, at 3:16 AM, Geert Janssens
> wrote:
>
> Our build system behaves differently when a build is started from a git
> cloned repository or from a release tarball: swig interface files are
> only converted into c files when building from git. The tarball assum
Our build system behaves differently when a build is started from a git
cloned repository or from a release tarball: swig interface files are
only converted into c files when building from git. The tarball assumes
these should be present.
What is the original reason it was implemented this way
> On Dec 30, 2014, at 3:56 AM, Geert Janssens
> wrote:
>
> On Wednesday 24 December 2014 08:38:06 John Ralls
> > ... although the SWIG folks still have some work
> > to do to fully assimilate C++11 [1].
> >
> >
> > [1] http://www.swig.org/Doc3.0/
On Wednesday 24 December 2014 08:38:06 John Ralls
> ... although the SWIG folks still have some work
> to do to fully assimilate C++11 [1].
>
>
> [1] http://www.swig.org/Doc3.0/CPlusPlus11.html
I'm taking this line out of its wider context of the python wrapper discussion
Nevermind; I just did it myself..
-derek
On Wed, March 12, 2014 3:11 pm, Derek Atkins wrote:
> Hi,
>
> All the rest of the Makefiles use $(SWIG) instead of @SWIG@
> Could you adjust your patch to match?
>
> Thanks,
>
> -derek
>
> On Wed, March 12, 2014 3:07 pm, E
Hi,
All the rest of the Makefiles use $(SWIG) instead of @SWIG@
Could you adjust your patch to match?
Thanks,
-derek
On Wed, March 12, 2014 3:07 pm, Erik Johansson wrote:
> On e.g. Ubuntu, swig is available under the name swig2.0.
>
> See attached patch.
>
> // Erik
>
>
On e.g. Ubuntu, swig is available under the name swig2.0.
See attached patch.
// Erik
--
Erik Johansson
Home Page: http://ejohansson.se/
PGP Key: http://ejohansson.se/erik.asc
From cd92fb6e54e5e1baca7e0944086a7838edc41726 Mon Sep 17 00:00:00 2001
From: Erik Johansson
Date: Wed, 12 Mar 2014 20
Geert Janssens writes:
> Log:
> Require swig 2.0.10 when building from svn/git
This means that I cannot build svn/git on my Fedora 18 desktop anymore.
Can this change only be predicated on finding guile2? It should still
be perfectly valid to build on guile-1.8 with older swig. Is ther
On Monday 27 May 2013 21:58:36 Norbert Holze wrote:
> Hello Geert,
>
> I just updated swig and gnucash to the latest version. Working fine
> without any patches.
>
> Regards,
>
> Norbert
> ___
> gnucash-devel mailing li
Hello Geert,
I just updated swig and gnucash to the latest version. Working fine
without any patches.
Regards,
Norbert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Christian Stimming writes:
>> Several people reporting that swig-runtime.h wasn't being created.
>> That's because '.' wasn't in the front of the SUBDIRS, so the Makefile
>> wasn't building the local targets.
>
> Right, I forgot to correctly
Am Montag, 28. März 2011 schrieb Derek Atkins:
> Author: warlord
> Date: 2011-03-28 11:58:00 -0400 (Mon, 28 Mar 2011)
> New Revision: 20499
> Trac: http://svn.gnucash.org/trac/changeset/20499
>
> Modified:
>gnucash/trunk/src/Makefile.am
> Log:
> Several people re
> Regards,
> Manfred
>
>
> On Sun, 27 Mar 2011 00:52:19 +0530
> Rohan Kulkarni wrote:
>
>> Hi,
>>
>> I am trying to build the latest source 2.4.x of gnucash, downloaded
>> through svn checkout.
>> The dependencies are all resolved but I get the fo
ote:
> >> Hi Rohan,
> >>
> >> I had the same error yesterday, but thought it was due to me using
> >> git.
> >>
> >> After a 'make dist' the file was there and the build succeeded.
> >>
> >> Maybe it is at least a worka
;
>> After a 'make dist' the file was there and the build succeeded.
>>
>> Maybe it is at least a workaround until this is permanently fixed.
>>
>> Regards,
>> Manfred
You certainly should not have to run "make dist" to get the
swig-ru
x27;
gnc-hooks.c:30: fatal error: swig-runtime.h: No such file or directory
I am installing gnucash on Ubuntu 10.10, using the swig version 1.3.40
Any suggestion on fixing the error?
Thanks,
Rohan
___
gnucash-devel mailing list
gnucash-dev
rni wrote:
> Hi,
>
> I am trying to build the latest source 2.4.x of gnucash, downloaded
> through svn checkout.
> The dependencies are all resolved but I get the following error
> during 'make'
>
> gnc-hooks.c:30: fatal error: swig-runtime.h: No such file or dire
Hi,
I am trying to build the latest source 2.4.x of gnucash, downloaded
through svn checkout.
The dependencies are all resolved but I get the following error during
'make'
gnc-hooks.c:30: fatal error: swig-runtime.h: No such file or directory
I am installing gnucash on Ubuntu 10
be careful about doing this wholesale. There are places where
> we have both xaccFooXXX and gnc_foo_xxx functions and they perform
> different operations. So make sure the target function does not exist
> before you rename.
>
> Also keep in mind you'll need to update the swig fi
in mind you'll need to update the swig files, and all the scheme
code.. and that gnc_foo_xxx is gnc-foo-xxx in scheme.
I'm just concerned that this is a bit late in the 2.4 release cycle to
do this change. Had you proposed it before 2.3.0 then I think it would've
been fine, but
Am Mittwoch, 9. September 2009 20:48 schrieb Phil Longstaff:
> Yes, I do need to revert that change. Thanks. In fact,
> gnc_account_get_full_name() just calls xaccAccountGetFullName().
Yes, I've seen that as well and I wondered why this is the case.
> Any
> reason I shouldn't go through all o
dized naming for 2.4?
Phil
From: Christian Stimming
To: gnucash-devel@gnucash.org
Sent: Wednesday, September 9, 2009 2:36:53 PM
Subject: Re: r18303 - gnucash/trunk/src - Use SWIG properly to wrap functions
to free strings which need to be freed by the caller.
Dear
>gnucash/trunk/src/html/gnc-html.c
>gnucash/trunk/src/html/gnc-html.h
>gnucash/trunk/src/html/gnc-html.i
>gnucash/trunk/src/report/report-gnome/gnc-plugin-page-report.c
>gnucash/trunk/src/report/report-gnome/window-report.c
> Log:
> Use SWIG properly to
Charles Day writes:
> Either that or gnc_guid2scm(guidnull()) ??
> I'm not sure why it is the way it is, nor am I sure what it SHOULD be.
> SCM_BOOL_F probably is correct.
>
> qof_instance_get_guid() can return a normal GUID, guid_null(), or NULL (upon
> failure). So it seems there ou
On Wed, Feb 18, 2009 at 7:03 AM, Derek Atkins wrote:
> Charles Day writes:
>
> > I have a question about the current type mapping that swig does for GUID
> > pointers. Currently, if a C function returns a GUID* that is a null
> pointer
> > (== NULL), swig converts it
Charles Day writes:
> I have a question about the current type mapping that swig does for GUID
> pointers. Currently, if a C function returns a GUID* that is a null pointer
> (== NULL), swig converts it to SCM_UNDEFINED and hands that to guile. From
> src/base-typemaps.i:
> %ty
I have a question about the current type mapping that swig does for GUID
pointers. Currently, if a C function returns a GUID* that is a null pointer
(== NULL), swig converts it to SCM_UNDEFINED and hands that to guile. From
src/base-typemaps.i:
%typemap(out) GUID * " $result = ($1) ? gnc_gui
Hi,
sometimes I need a little longer ... ;-)
Am Dienstag, 12. August 2008 05:47:31 schrieb David Reiser:
> On Aug 11, 2008, at 10:43 AM, Christian Stimming wrote:
:
> > What I did with my OpenSuSE 10.2 was simply this: I manually compiled
> > and installed swig-1.3.31 from
ll stay until I have the time, to update my system.
>
> What I did with my OpenSuSE 10.2 was simply this: I manually compiled
> and installed swig-1.3.31 from a tarball, with ./configure
> --prefix=/usr. In effect, this blatantly ignores the package manager
> and audaciously installs a
s simply this: I manually compiled
and installed swig-1.3.31 from a tarball, with ./configure
--prefix=/usr. In effect, this blatantly ignores the package manager
and audaciously installs a newer swig on top of the package manager's
one. However, starting from a clean checkout gnucash w
:30:12 schrieb Christian Stimming:
> > I think it's perfectly reasonable to increase the required swig version
> > to 1.3.31. I'll commit this in a minute.
>
> Hm, after some time out of town, I wanted to test all the nice patches,
> which Charles in between applied on
Am Dienstag, 15. Juli 2008 10:30:12 schrieb Christian Stimming:
:
> I think it's perfectly reasonable to increase the required swig version to
> 1.3.31. I'll commit this in a minute.
Hm, after some time out of town, I wanted to test all the nice patches, which
Charles in betwe
t;
> If we're going to do this, we shouldn't just add it to SWIG_PYTHON_OPT,
> but somewhere that will be used by all invocations of swig within
> GnuCash, as this isn't a swig -python specific problem. Someone else may
> wish to run gnc-numeric.h through swig sometime. (when they
shouldn't just add it to SWIG_PYTHON_OPT,
but somewhere that will be used by all invocations of swig within
GnuCash, as this isn't a swig -python specific problem. Someone else may
wish to run gnc-numeric.h through swig sometime. (when they attempt to
write Java bindings, *shudder*. )
> Gnucash currently requires only swig 1.3.28. We either need to upgrade this
> (on trunk) to 1.3.31 or we need to add a workaround for versions lower than
> 1.3.31, which would mean adding "-Dinline=" to SWIG_PYTHON_OPT.
Given that it was released in November 2006, I think
6...)
>
> Gnucash currently requires only swig 1.3.28. We either need to upgrade this
> (on trunk) to 1.3.31 or we need to add a workaround for versions lower than
> 1.3.31, which would mean adding "-Dinline=" to SWIG_PYTHON_OPT.
Either way. I'm happy to just require 1
Am Mittwoch, 9. Juli 2008 00:09 schrieb Mark Jenkins:
> Christian Stimming wrote:
> > By the way, one very weird error that I get with SWIG-1.3.31 and your
> > python/swig bindings is this:
>
> ...
>
> > Turns out swig doesn't like the "inline" keyword
Christian Stimming wrote:
> By the way, one very weird error that I get with SWIG-1.3.31 and your
> python/swig bindings is this:
...
> Turns out swig doesn't like the "inline" keyword at all of the places in the
> header. If I add the option
>
> -Di
; mentions. (see details earlier in thread)
>
> For now, you can get a patch from last month at
> http://savannah.nongnu.org/projects/python-gnucash
>
> configure with --enable-python-bindings
By the way, one very weird error that I get with SWIG-1.3.31 and your
python/swig binding
"Charles Day" <[EMAIL PROTECTED]> writes:
> True. HOWEVER it does look like swig has some built-in documentation
> capabilities. (See <http://www.swig.org/Doc1.1/HTML/
> Documentation.html> )
> According to that we can genera
Hi,
On Mo, 2007-02-26 at 20:17 -0600, Paul J Stautzenberger-Crown wrote:
> In-Reply-To=45E38082.1060601%40crownpride.com
>
> I added -
>
> export PATH='$PATH:/p/Develop/gnucash/svn/bin'
>
> re-ran -
>
> /p/Develop/gnucash/packaging/install.sh
>
> Problem solved.
>
> Thanks.
Install.sh shoul
In-Reply-To=45E38082.1060601%40crownpride.com
I added -
export PATH='$PATH:/p/Develop/gnucash/svn/bin'
re-ran -
/p/Develop/gnucash/packaging/install.sh
Problem solved.
Thanks.
Paul
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://
Hi,
Quoting Paul J Stautzenberger-Crown <[EMAIL PROTECTED]>:
> Greetings,
>
> The error I am getting is
>
> "It looks like you are NOT building from Subversion
> but I cannot find swig-runtime.h. Check your PATH
> and make sure we can find svnversion in you
Greetings,
The error I am getting is
"It looks like you are NOT building from Subversion
but I cannot find swig-runtime.h. Check your PATH
and make sure we can find svnversion in your PATH!
Either that or contact gnucash-devel@gnucash.org because
the tarball you downloaded is broken."
> You would still need to wait for someone to create a swig wrapper for
> your specific language.
Ok, thanks.
> Also, it's unlikely you'd be able to write a report per se in a
> different language even if someone did write the bindings for you.
> The fact that we'r
I wrote:
> (Ubuntu users can use the repository with these lines
> deb http://carrot:3142/repo.parit.ca/ dapper/
> deb-src http://carrot:3142/repo.parit.ca/ dapper/
> )
Oops, I copied and pasted without looking carefully. Should of been:
deb http://repo.parit.ca/ dapper/
deb-src http://repo.parit
Once again, please forgive my swig/g-wrap ignorance, but what does this
mean for a guy like me who would love to be able to automate some
GnuCash-related tasks or create text reports using Perl or Python?
Would I still need to wait for someone to create a swig wrapper that's
specific to a lan
You would still need to wait for someone to create a swig wrapper for
your specific language. Also, it's unlikely you'd be able to write
a report per se in a different language even if someone did write
the bindings for you. The fact that we're using swig should make
those bindi
>> It looks like someone created python bindings, using swig, against
>> 1.9.8.
>
> Hi, I'm the developer. The website is out of date. I have a newer
> version in our apt repository that is built against 2.0.1
>...
> The code's in rough shape, which is why I
Just so you're aware, GnuCash SVN (trunk) has switched from g-wrap to
swig for the guile bindings, so that may make it even easier for you
going forward.
-derek
Quoting Mark Jenkins <[EMAIL PROTECTED]>:
> Josh Sled wrote:
>> It looks like someone created python bindings,
Hi,
On Do, 2007-01-18 at 09:21 -0600, Mark Jenkins wrote:
> Josh Sled wrote:
> > It looks like someone created python bindings, using swig, against
> > 1.9.8.
>
> Hi, I'm the developer. The website is out of date. I have a newer
> version in our apt repositor
Josh Sled wrote:
> It looks like someone created python bindings, using swig, against
> 1.9.8.
Hi, I'm the developer. The website is out of date. I have a newer
version in our apt repository that is built against 2.0.1
http://repo.parit.ca/dapper/python-gnucash_0.7.29-1.
It looks like someone created python bindings, using swig, against
1.9.8.
http://www.parit.ca/projects/pythongnucash
--
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
usiness/business-reports/aging.scm
>gnucash/trunk/src/business/business-reports/invoice.scm
>gnucash/trunk/src/import-export/qif-import/qif-file.scm
>gnucash/trunk/src/report/report-system/report.scm
> Log:
> Fix three incorrect tests for swig-wrapped objects and one
>
1 - 100 of 152 matches
Mail list logo
