views:

193

answers:

3

I have a small ANSI C application which compiles cleanly under different tested compilers and platforms. It doesn't use any preprocessor switches or external dependencies and the makefile is simply something like:

myapp: *.c
    gcc *.c -Wall -o myapp

If I want to distribute this project in source form as portable as possible, should I wrap it using automake/autoconf? Will this actually increase portability or is it as portable as it gets as it is?

The only thing I can think is that it will automatically select the systems compiler but it will also add a lot of complexity. Is it worth it?

+4  A: 

I doubt it's worth it. ANSI C without any OS-specific calls should be supported on every platform that has a working C compiler and adding automake/autoconf to this makes maintenance probably less pleasant than currently.

You can, however, use the $(CC) variable in your makefile to automatically use the system's compiler:

myapp: *.c
    $(CC) *.c $(CFLAGS) -o myapp
Joey
I'd use `$(CC)` together with `$(CFLAGS)` and `$(CPPFLAGS)` and `$(LDFLAGS)` - and leave out the `-Wall` as that looks gcc specific.
ndim
Agree - don't use autoconf. Note ndim's comment.
Jonathan Leffler
A: 

Although you may feel you'll gain little in terms of functionality, you may still wish to consider it for these reasons:

  • Using autoconf is a very common way of distributing C code. Consequently, most people should be comfortable with building and installing using that, which makes it easier for the user.
  • Once you've put in the effort of getting autoconf working with your project, it will make it substantially easier if and when you do want to make use of some of its additional functionality.
Tim
On the other hand, if the 'INSTALL' file (or, more likely, the README file) says: To compile, run "make" - people will know what to do.
Jonathan Leffler
You're absolutely right, and in the end it's the author's choice. However, I have recently had reason to write a script to automate the unattended installation of a large number of packages. All the ones which used autoconf needed the same treatment and were relatively straightforward to deal with. Packages which used something non-standard needed individual attention and effort and were a real nuisance.
Tim
There is something to be said for getting predictable 'make install' and 'make uninstall' targets for free. If people should just build the binary and run it, leave it as is. If people will install the binary, then I'd move to the autotools.
Rhys Ulerich
+1  A: 

You don't need to specify a compilation rule, thus there is no need in $(CC), $(CFLAGS) and $(LDFLAGS), because make has an implicit rule to make an executable from C source.

Keep your Makefile simple:

all: myapp

myapp: *.c

clean:
    rm -f myapp

.PHONY: all clean

BTW it would be better to specify a list of source files because there is no guarantee that your sources will be the only C files in that directory

qrdl