automake, autoconf etc..

[Neo]

Does anyone here use these auto* tools. I would like to have a look at how they are written for a projects.
I have gone through the GNU pages but they could'nt figure out much

[Pype.Clicker]

honnestly, i don't use them ... they've never really convinced me in first place, but that's maybe because i started clicker development in an environment where they weren't easily accessible (e.g. DJGPP)

i rather use my own 'filters' from GCC -M output for dependencies.

[erikgreenwald]

They're pretty easy to use, I picked 'em up in '96 and have adored them every since... Probably the best way to get into them is to grab a few simple projects and look at their .am/.ac files... "autoreconf -vi" is a useful command, and you can easily reduce a set down to a minimal template (for the configure.ac file, sometimes misnamed configure.in). If you run into a specific problem, I'm sure I'd be more helpful with that than something as open ended as this

-Erik

[Neo]

I have been planning to restructure my project and start using these tools to let me get a feel of them. What I am looking for right now is a way to let me build all the c/asm files in each subfolder into a obj/lib file with the name of the subdir as the lib filename.
And then finally combine these all into the final bin file which my bootloader loads and gives control to.
Right now I don't know whether I should start from the subdirs or the main root dir.
I think it would be easier as a first step if I first get these tools to generate obj/lib files from the subdirs. any help on this?
Or should i do it the other way round (doesn't make much sense this way ???)

[Colonel Kernel]

I started reading a book on automake & autoconf, and quickly decided that it was overkill for my project. It seems way too complex to me. It also seems geared pretty much exclusively at creating your own GNU-ish packages to be distributed as source, which is not what I want.

I ended up creating a set of make "macros" that use $eval to generate whatever kind of rules I need. The only problem was that I had to use make 3.81 beta (at the time... I think the final 3.81 release is out there by now), since 3.80 had a bug in $eval that limited its usefulness. I sure banged my head against the wall writing those makefiles though...

[Neo]

I had the feeling that it seemed too GNU'ish myself, but would it better in the long run to have automake, autoconf do the stuff for me rather than having to write Makefiles manually? (which is what I am doing now).

[Colonel Kernel]

The idea behind those $eval macros I did was that writing makefiles from that point on should be trivial, but you should still have enough flexibility to have different projects in different sub-dirs, and different configurations of those projects, etc.

For example, here is one of the makefiles for my OS project (the number of source files is small but will grow over time):

Code: Select all

include ../../Build/Makefile.include
include ../Build/Makefile-kernel.include

# Assign some variables that will be common across all architectures.
KRunTime_sources      = DisplayTextStream.c \
                    KOut.c \
                    KShutdown.c \
                    SynchronizedTextStream.c \
                    TextWriter.c

KRunTime_includedirs   = ../../../Include
KRunTime_targetdir      = ../../../Lib
KRunTime_target         = libKRunTime.a

# Assign the configurations to each "project" according to architecture...
KRunTime_x86_uni_configs      = $(kernel_x86_uni_configs)
KRunTime_x86_uni_sources      = $(KRunTime_sources)
KRunTime_x86_uni_includedirs   = $(KRunTime_includedirs) \
                           ../../../Include/Kernel/Architecture/x86 \
                           ../../../Include/Kernel/Architecture/x86_uni
KRunTime_x86_uni_targetdir      = $(KRunTime_targetdir)
KRunTime_x86_uni_target         = $(KRunTime_target)

# Make sure the generated rules can find all the sources.
VPATH = ../Architecture/x86/KRunTime

$(eval $(call createStandardPrologue,KRunTime_x86_uni))
$(eval $(call createStandardLibRules,KRunTime_x86_uni))

The magic is all in the macro calls at the bottom, which come from the include files included at the top. I don't have any problems maintaining makefiles that are this simple, so I see no need to use the auto* tools.