running from build dir

[Chris Shoemaker]

On Thu, Dec 23, 2004 at 12:07:59AM +0000, Neil Williams wrote:
> 
> Make install runs make if anything needs to be updated anyway - it'll bail out 
> if there's an error with the make. The only difficulty is if you make an 
> obvious typo, the relevant error line can be a long way back in the output so 
> I run a make in the IDE (where the typo will be clearly highlighted) before 
> going for the terminal.
> 
> make runs gcc etc.
> make also runs libtool
> make install runs gcc+libtool via make and then runs the install.
> 
> Errors at any stage cause the next stage to bail out.
> 

Thanks for explaining that, Neil.  It's clear now.

> > I don't know much about Anjuta, but I'm a bit wary of heavy-weight
> > IDEs, because I use some pretty ancient hardware.  Do you find Anjuta
> > resource-friendly?
> 
> It does my CVS for me, it looks up functions and variables for me - no matter 
> where the source file is - it auto-completes function and variable names, 
> automatically lists all the required argument types for any function as you 
> type the code - even ones I defined not 10 seconds before - VERY good syntax 
> highlighting, a handy terminal window, copes easily with all the projects 
> I've thrown at it so far (which KDevelop couldn't) and doesn't write massive 
> project files. I suspect the fact that Anjuta isn't part of KDE explains why 
> it copes with Gnome projects better than KDevelop. Anjuta will also work with 
> Glade but the GnuCash setup doesn't suit that role.

Sounds nice.  Maybe I'll give it a try.  I tried Kdevelop about 1.5 years ago and was unimpressed.  Eclipse was nicer, but too hungry for me.

> > If this were a pure C 
> > app, I would suggest a dependence on an environment variable(s) for
> > finding all the needed files.
> 
> With an app the size of GnuCash that gets incredibly messy. There are a lot of 
> files that simply don't need to get copied around for every user, they just 
> need to be in a single place for each installation, no matter how many users 
> are using the rest of the app. The example accounts are a good example.

You bring up a point I hadn't even considered: copying files for each
user.  I only consider the single-user aspects of gnucash.  I was
imagining this kind of scenario:

mv /opt/gnucash /opt/gnucash-baseline
./configure --prefix=/opt/gnucash --enable-opt-style-install
make && make install  ( or, as per above, simply 'make install')
/opt/gnucash-baseline/bin/gnucash &
/opt/gnucash/bin/gnucash &

This doesn't work as expected, because both processes end up running
binaries in /opt/gnucash/.

> 
> > Is this more difficult with Scheme, or 
> > is there some other reason to prefer fixing paths at install-time?
> 
> Keep it simple.
> 
> There are lots of examples in the tree of how to convert an option given 
> to ./autogen.sh --prefix into a file that can be included into your C source. 
> One is gnucash/src/gnome-utils/gnc-dir.h 

That's a good example.  I can see that with this idiom it's not a big
development burden to reference full paths.  And, of course, a dirname
binding at run-time is less efficient than one at compile-time (or in
this case, configure-time).  OTOH, 

#define GNC_GLADE_DIR "@-GNC_GLADE_DIR-@"

isn't a whole lot simpler than something like

#define GNC_GLADE_DIR getenv("GNC_GLADE_DIR");

especially considering we've already made gnucash-env responsible for
environment preparation.  In that case, something like

sed -ie "s:/opt/gnucash:/opt:gnucash-baseline" \
 /opt/gnucash-baseline/bin/gnucash-env

could conceivably fix the example above and make the whole
installation "portable".

(Incidentally, I've got a feeling that runtime dirname binding might
make running from the builddir much easier, too.)

Am I missing something?

-chris