install.sh script for win32
warlord at MIT.EDU
Sat Aug 26 20:00:20 EDT 2006
Christian Stimming <stimming at tuhh.de> writes:
> Concerning LN_S, this one bites us hard everywhere throughout gnucash. In a
> lot of places, we do
> $(LN_S) . gnucash
> which, if symlinks are unavailable, results in
> cp . gnucash
> which either fails (due to the directory and no -R) or tries to copy
> everything recursively into itself...
Yeah, this is definitely a problem. In MOST cases it's only required
to run gnucash from the build tree. I'm pretty happy to not worry about
that here. HOWEVER, there's another problem, which is that we really
need the "g-wrapped" location....
> I'm inclined to propose really changing all these LN_S into a manual copying
> and for all those scheme modules this would be
> mkdir gnucash
> cp $(gncmod_DATA) gnucash
> or similar... I've written about this on the wiki page in the "symlinks"
That's certainly one option..
> There's one intermediate solution before we start to change all
> Makefile.am of gnucash: The install.sh script could visit all those
> directories and execute the necessary steps by hand:
> mkdir g-wrapped; mkdir gnucash;
> make `grep noinst_.*_DATA Makefile.am | cut -d: -f2` # generate g-wrappers
> cp gw-*.scm g-wrapped
> cp *.scm gnucash # need to select the correct files here
I dont think this has to be done from install.sh. I think the
makefiles can (should?) just be changed to do this. This way we can
clean it up via "make clean". I think the only things that need to be
copied are the g-wrapped scheme files.
>> Once these are done we should DEFINITELY change the script to just pull
>> down the binaries.
> The binary goffice is available there as well, except it only has a
> libgoffice-0.3.pc whereas gnucash expects a libgoffice-1.pc.
That's fine. I've fixed the gnucash configure script to handle this.
*sighs* All this work to get gsf and goffice to build, and you've got
binaries. ;) I guess we should just add an "inst_foo_bin()" function
to install the binary version of "foo" instead of the source version.
That way we keep the code that builds it for future reference (or if
we want to change the dependencies).
>> I think this is a change that should be made in g-wrap itself. When
>> g-wrap generates the file is should output the correct name.
> Yes, that would be even better -- but OTOH I'm not totally sure
> whether g-wrap actually knows the SO_MAJOR version number, which is
> the one in use here. For now, gnucash always uses a zero, but as a
> general solution... anyway, we only need a solution for ourselves,
> so that's probably not a problem here.
Yeah, I think we can assume that we're the only user and that all the
libraries are major version 0. It's not like we've use libtool
library version numbers at all.. (we probably should going forward).
Hopefully all this will get MUCH easier once we move to swig. But for
now I think it's safe to just hard-code "-0" into g-wrap. Want me to
work on that, or do you want to work on it?
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
warlord at MIT.EDU PGP key available
More information about the gnucash-devel