running from build dir

Wed Dec 22 19:07:59 EST 2004

On Wednesday 22 December 2004 6:35 pm, Chris Shoemaker wrote:
> On Wed, Dec 22, 2004 at 05:05:29PM +0000, Neil Williams wrote:
> > Better to skip the make and go for make install from the directory where
> > you made your changes. I even skip between directories and run two or
> > three make installs in gnucash/src/engine and gnucash/src/gnome in less
> > time than it takes to do a full make install from gnucash/. I also cheat
> > - I edit the local Makefile.am to remove test files in directories
> > beneath the current one from the build until I actually need to test.
> > (top tip: remember to put them back!)
>
> Are you sure that is holds when editting .c files, too?

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.

> My 
> understanding is that make install is sufficient for modified scm
> files, but modified .c requires make.

Not necessarily as a separate action: make install is sufficient.

> I think Derek implied exactly 
> this is this thread.

No, Derek said:

> > I just "make install" every time.  Note that if you only change
> > source files (not headers) then you only need to make install
> > in the directories you've changed rather than "make install" in
> > the full source tree.  If nothing else it saves a bit of time.
> > 

So he uses make install as well. The point is WHERE you start the make 
install. If you're messing with headers (creating new typedef's, new structs, 
changing function argument lists or return types etc.) then you need to take 
account of other parts of the program that may include that header and which 
will now break - horribly. If you don't use make install in that directory, 
the previously compiled libraries will try to access your code using the OLD 
structures. As you might expect, that will not be pretty.

I've just done this to solve a problem that Derek spotted with my code - I've 
had to redefine a lot of the functions so that they avoid using a static 
variable. That's now done but it meant changing each part of the GnuCash that 
used that header file. That's why I was running make install from 
gnucash/src/gnome and gnucash/src/engine for the same operation. I was 
editing engine/qof_book_merge.h and .c and editing gnome/druid-merge.c at the 
same time. The gnome/ C code uses the engine/ C code as a library, so the 
engine code must be recompiled first and then the gnome code re-linked 
against the updated library - not the other way around.

(I've got an issue or two remaining on that, Derek, I'll send the patch once 
that's done.)

> > So I use Shift+F9 from Anjuta to build within the IDE according to the
> > relevant Makefile relating to the file being edited. That makes sure I
>
> Perhaps Shift+F9 is equivalent to 'make'?

Only within Anjuta - different IDE's have different key shortcuts. Within 
Anjuta, shift-F9 compiles the file following the rules in the Makefile - it 
doesn't link it, just compiles.

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

Anjuta coped very well on a PIII 700 with 128Mb. It was only when I needed to 
run a web browser, email and other bits at the same time that I needed to go 
up to 384Mb RAM - not because of Anjuta but because the make was using swap 
space and getting v.v.slow.

> Is it considered undesirable for the installed
> binaries to be sensitive to their location?

Of course - you cannot know where the user is going to install the app. All 
you can do is use the config and Makefile settings to set a location below 
whichever --prefix the user specifies.

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

> 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 

-- 

Neil Williams
=============
http://www.dclug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20041223/d676cf34/attachment.bin