automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Workflow


From: Nick Bowler
Subject: Re: Workflow
Date: Tue, 7 May 2013 10:40:37 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On 2013-05-06 21:10 +0200, Martin Kalbfuß wrote:
> I write/change code or data. Then I compile. If it compiles and links
> properly, I run some automated tests and run the program to test it
> manually. It's an gui application so automated tests are a bit
> difficult. The last step is important. But that's exactly the problem.
> 
> I do ./configure --prefix=mydebugdir once.
> Then I do make && make check. Here's the first Problem. My program needs
> Data. So I pass in the data path with my CPPFLAGS. But that's the path
> when installed. So I have to install my app first before I can test it.
> I found installcheck. But it seems to be unused. I'm a bit confused. In
> total I have to call
> 
> make && make check && make install && make installcheck &&
> path_to_program/program && make uninstall
> 
> This is a lot for such a common thing. What I'm doing wrong here?

The fundamental problem is that making programs runnable from the build
tree is somewhat non-trivial, and requires both the build system and
the program itself to be designed together for it to work.  There are
a number of different options to handle this, with no clear winning
solution.  Here's just a few possibilities:

- A simple way is pretty much what you're currently doing: configure the
  package with its prefix as a subdirectory of the build directory.  You
  can then do make install-data to copy the data files.  There is no
  need to uninstall the files, you can just leave the installed data
  there (just remember to run make install-data again whenever they are
  modified) and your program will find them in that location as you are
  developing it.  This approach works reasonably well for data files
  that are not changed often.

- Another approach is to have your data files arranged in your source
  tree in a compatible manner to how they will be arranged when
  installed, and then add a runtime option to make your program able to
  find its files from that location (an environment variable works well
  because you can set it once and then forget about it).  You can even
  have your build process spit out shell script wrappers to invoke the
  program with the correct options (libtool does this for linking
  against shared libraries that are not installed).

- A third option is to design your program to be relocatable (e.g.,
  using the Gnulib relocatable-prog module).  You can then arrange for
  the build tree to look like the install tree, and your program can
  find its data files automatically when run normally.

Hope that helps,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]