[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 7 May 2013 10:40:37 -0400
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/)
- Workflow, Martin Kalbfuß, 2013/05/06
- Re: Workflow, Dan Kegel, 2013/05/06
- Re: Workflow,
Nick Bowler <=