[SOLVED] Using autotools

songangel · 04-13-2009, 09:43 AM

Hi guys,

I am a long time C programmer but have little experience in writing programs for Linux. I am writing a game using the allegro game library and I will be using the GNU autotools for packaging.

How do I know where my data files (images,sounds,etc) will be stored when the user does `make install`? I'm thinking that there must be something in config.h that I could use in my source code.

Example:

I have data files stored in a subfolder of the project named "data".

Code:

dat=load_datafile("data/data.dat");

This would work fine while building and testing, but...

Any ideas?

Sergei Steshenko · 04-13-2009, 03:02 PM

Quote:

Originally Posted by songangel

Hi guys,

I am a long time C programmer but have little experience in writing programs for Linux. I am writing a game using the allegro game library and I will be using the GNU autotools for packaging.

How do I know where my data files (images,sounds,etc) will be stored when the user does `make install`? I'm thinking that there must be something in config.h that I could use in my source code.

Example:

I have data files stored in a subfolder of the project named "data".

Code:

dat=load_datafile("data/data.dat");

This would work fine while building and testing, but...

Any ideas?

You as the developer define a directory tree structure and stick to it.

You decide in which part of the tree data files reside.

A program is capable of getting its full path - isn't it argv[0] in "C" ? Anyway, it's $0 in, for example, Perl.

Knowing full path to your program you can code access to every other element of your tree.

You program is also portable in such a manner.

songangel · 04-13-2009, 03:55 PM

Quote:

Originally Posted by Sergei Steshenko

You as the developer define a directory tree structure and stick to it.

You decide in which part of the tree data files reside.

A program is capable of getting its full path - isn't it argv[0] in "C" ? Anyway, it's $0 in, for example, Perl.

Knowing full path to your program you can code access to every other element of your tree.

You program is also portable in such a manner.

I appreciate the response but perhaps I didn't make my problem clear enough, so please let me clarify my question by responding to your reply:

Quote:

A program is capable of getting its full path - isn't it argv[0] in "C" ? Anyway, it's $0 in, for example, Perl.

True but the executable will be installed by itself without my datafiles. My understanding is that it's bad practice to install data files in the bin directory correct? So again, how will I know where my data files will be stored?

Quote:

Knowing full path to your program you can code access to every other element of your tree.

Again, this isn't quite true since binaries will be installed separately right? I have a data subdirectory in my projects folder now but won't that change after the end user does `make install`?

I guess my real question is how to I "tell" the autotools where it should put my files so that I will know how to hard code the correct path?

Better still, is there a DEFINE in a header file somewhere that could be filled in during the configure process by the end user so that no matter where they installed the program, the data files could still be found by the executable?

I read that the user can change the DESTDIR by passing it to configure, but again I'm new to programming in Linux so I need someone to point me in the right direction.

I certainly don't mind reading the docs if I know what docs to read. I should mention that I read the automake info page and could not find an answer.

Thanks for the reply.

Sergei Steshenko · 04-13-2009, 06:28 PM

Quote:

Originally Posted by songangel

I appreciate the response but perhaps I didn't make my problem clear enough, so please let me clarify my question by responding to your reply:

True but the executable will be installed by itself without my datafiles. My understanding is that it's bad practice to install data files in the bin directory correct? So again, how will I know where my data files will be stored?

Again, this isn't quite true since binaries will be installed separately right? I have a data subdirectory in my projects folder now but won't that change after the end user does `make install`?

I guess my real question is how to I "tell" the autotools where it should put my files so that I will know how to hard code the correct path?

Better still, is there a DEFINE in a header file somewhere that could be filled in during the configure process by the end user so that no matter where they installed the program, the data files could still be found by the executable?

I read that the user can change the DESTDIR by passing it to configure, but again I'm new to programming in Linux so I need someone to point me in the right direction.

I certainly don't mind reading the docs if I know what docs to read. I should mention that I read the automake info page and could not find an answer.

Thanks for the reply.

When I build FOSS targets, I always use --prefix==/desired/root , e.g.:

./configure --prefix=/mnt/sdb8/sergei/AFSWD_debug/install/readline-5.1

, so, the standard tree will be located under /mnt/sdb8/sergei/AFSWD_debug/install/readline-5.1 :

Code:

sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug> ls -ltrF /mnt/sdb8/sergei/AFSWD_debug/install/readline-5.1/ | grep '/$'
drwxr-xr-x 3 qemu users 1024 2009-02-23 17:17 man/
drwxr-xr-x 2 qemu users 1024 2009-02-23 17:17 lib/
drwxr-xr-x 2 qemu users 1024 2009-02-23 17:17 info/
drwxr-xr-x 3 qemu users 1024 2009-02-23 17:17 include/
drwxr-xr-x 2 qemu users 1024 2009-02-23 17:17 binsh/
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug>

so, with 'configure' capabilities the question boils down to "how do I tell auto tools about extra directories in the tree ?".

I am not an autotools expert, and I was trying to suggest you a different/more particular direction of thinking.

Whenever I can (and with my own code I alway can) I rely on directory structure and elastic root of it.

Hko · 04-13-2009, 06:29 PM

Quote:

Originally Posted by songangel

True but the executable will be installed by itself without my datafiles. My understanding is that it's bad practice to install data files in the bin directory correct? So again, how will I know where my data files will be stored?

It's correct that it is bad practice to store data file in any "bin" directory.

What is good practice in this respect you can find here:
http://www.pathname.com/fhs/
http://en.wikipedia.org/wiki/Filesys...archy_Standard

In (very) short, for software meant for non-root/boot users and installed by packages from the linux-distribution itself:

Executables go in /usr/bin
Data files which are not meant to change after installation go in /usr/share/<package-name>
Data files which will be written to after installation (databases, log etc..) go in /var/<package-name>
Documentation goes in /usr/share/doc (man-page files in /usr/share/man)
Configuration files go in /etc

For software installed from source by the local administrator there is a similar hierarchy in /usr/local. Software not built from source, go here as well or in /opt. /opt is often empty after installation of the operating system. Where /usr/local often is already filled with (empty) directories like bin, var, share,...

So for your program (distributing from source, I assume) the default install prefix should be /usr/local. Your executables go in /usr/local/bin.

Assuming your data won't be written to after installation, they should go in /usr/local/share/<software-name>/images and /usr/local/share/<software-name>/sound.

How your program knows where to find them is a thing I've been googling for a few years ago. I found out that the (conventional?) best way is to have the absolute path #define'd at compile time (so hardcoded in the binary executable that is to be installed).

But the installing person may still choose from the prefixes /opt, /usr/local, some user home directory, or /usr (/usr conventionally only when packaging it for a distribution. See above) or another unusual place.

At compile/install-time this prefix is set by the installing person by means of the ./configure script as generated by your autotools. The autotools do not have a ready-made solution for such data-files (at least not at the time I was figuring out.). So I made a template/example package for this. Sort of "hello world" with data files with autotools. You can find it here. It makes a --datadir option available for the configure script generated by the autotools. Please note that it is for old autotools, so you may need to change things.

But you said that your data-files will be installed seperately from the executable(s). So, it might be even possible that a different person will be installing the datafiles. Then they might be anywhere! To deal with that you would need to assume that the person who install the data knows where the executables are stored, and that he/she will correctly use the same prefix and/or --datadir option.

Another way could to install a configuration file in /etc (/usr/local/etc is not specified by the conventional standards, but is IMHO a proper way). The program can the read the data-directory from that file. That way it can be pretty easily be adjusted after installation. (and yes, you hardcode the path /etc/<prog-name>.conf).

Hope this helps.

ntubski · 04-13-2009, 06:31 PM

I think the following page answers your question: 19.5 How Do I #define Installation Directories?

Quote:

A program is capable of getting its full path - isn't it argv[0] in "C" ?

Not always, the program that calls exec() gets to decide what argv[0] is. Most shells will put whatever you type in as the command line, eg:

Code:

~$ prog # argv[0] = "prog"
~$ /full/path/to/prog # argv[0] = "/full/path/to/prog"

So you would have to search in the PATH environment variable in the first case.

Hko · 04-13-2009, 06:46 PM

Quote:

Originally Posted by ntubski

I think the following page answers your question: 19.5 How Do I #define Installation Directories?

Ah! On that page I read that the autotools now do have a --datadir option.

Sergei Steshenko · 04-13-2009, 08:05 PM

Quote:

Originally Posted by ntubski

I think the following page answers your question: 19.5 How Do I #define Installation Directories?

Not always, the program that calls exec() gets to decide what argv[0] is. Most shells will put whatever you type in as the command line, eg:

Code:

~$ prog # argv[0] = "prog"
~$ /full/path/to/prog # argv[0] = "/full/path/to/prog"

So you would have to search in the PATH environment variable in the first case.

And for me the main point of http://www.gnu.org/software/autoconf...ng-Directories is this:

Code:

If you are using Automake, you should use AM_CPPFLAGS instead:

          AM_CPPFLAGS = -DDATADIR='"$(datadir)"'

, i.e. essentially, user defines directory structure, expresses it through (a number of if necessary) datadir(s) and passes this info to his/her program through "C" macros ultimately defined on command line.

songangel · 04-13-2009, 08:09 PM

Hko many thanks. This is a bit to digest, but I shall now delve into it further and experiment with a pseudo package to see where things will go after make install. You have provided some good reading material for me and I really appreciate it. I will post my results here in the hopes that it may help others.

songangel · 02-18-2010, 11:43 AM

After building many programs from source I've realized a few things. First, I mistakenly assumed that my binaries would go in /bin like system binaries, configuration files in /etc - etc! (a stupid assumption).

In reality I do indeed decide how the source tree would be laid out so really the prefix passed to configure by the user is irrelevant as long as I keep my "data" directories inside my top level directory. This means that pseduo code like load_bitmap("./data/data.file") will still work regardless of the chosen prefix.

I've also found that when installing some pre-built games that have a graphical installer seem to prefer to install to /usr/local or /opt by default whereas those built from source seem to install to /usr/share or /usr/local/share by default.

I know this reply is late, but it may help someone else.