ec429 wrote:
Don't rely on the sizes of integer types;
if you need an N-bit int, use intN_t.
I would go a bit further than that. It would be a good idea to define type
names for primitive data types in a separate header (config.h), either
through macro definitions or typedefs, and then set/update that definition
based on checks performed by the configuration script.
The GNU build system (i.e., autotools) was developed basically with this in
mind, through the use of a config.h.in file, and cmake also supports this as
well.
Hand-make a configure script that
tests for the things you need (by compiling and running tiny C programs)
and outputs that information into a file that gets included by your
Makefile (and defines some variable to hold some -D macro definitions
for the cpp).
I don't believe this suggestion is very good. Any flexibility which might be
gained by developing our own shell scripts may require a relevant amount of
maintenance and research, once we need to support more than one platform.
There were good reasons why smart people decided to invest their time
developing automated build systems in order to avoid hand-making configure
scripts.
Hand-roll your makefile too, using implicit rules (%, $<
and $@ are your friends), but if some targets don't support GNU make,
you may need to write a tool to generate an explicit makefile from your
implicit rules (such a tool would be easier to write in, say, perl, than
in C).
Again, this is the same problem I've previously pointed out. If someone
intends to avoid automatic build systems when developing portable projects
and instead they opt to rely on all sorts of custom hand-written scripts,
they are digging themselves into a hole from which they may experience a lot
of problems just to escape it.
Another aspect which is rarely taken into account by those who decide to
rely on a set of hand-crafted scripts to automate their build process is
that another advantage in relying on automated build systems is familiarity.
There is a wealth of information and discussion groups dedicated to specific
automated build systems, and a considerable number of developers already
have experience in writing/managing them. It is also terribly easy for any
developer who intends to use one to simply read up on them and, in a matter
of minutes, get them up and running. Therefore, it wouldn't be a challenge
for a clueless newbie to read up on a standard/popular build system and not
have a problem implementing basic stuff, such as adding files to a project.
The same doesn't necessarily apply to hand-crafted scripts. Once a project
grows after some point, the project's hand-crafted scripts tend to become,
at least to those who didn't developed them, a violent mix of arcane
enchantments and textual noise, which is practically impossible to
understand, let alone maintain and update. As those scripts represent a
one-off attempt at writing a build script, there won't be a lot of help
available to those who intend to decipher them. So, although a specific mix
of "let's hand-craft everything" may serve well a specific developer in that
very specific occasion, it may undermine the ability to contribute by anyone
else. And this is a problem.
On the more general note of avoiding Autotools, I would note that all my
open-source projects (there are several) use hand-written Makefiles,
none has a configure script, and I have yet to encounter anything more
severe than a few #ifdef WINDOWS to handle cross-compilation to that
platform (and separate make rules for Windows targets). With a
cross-compiling gcc, even Cygwin is not necessary (although it would be
if you wanted to /compile/ on Windows).
Like any tool ever developed, there is a threshold that marks the start of
its usefulness. Or, better yet, the point where applying that tool makes
sense.
Considering build automation tools, their usefulness only kicks in if they
actually help manage the build process. In some tiny, one-off projects,
even writing a simple makefile ends up being too much work which brings
little to no reward.
So, just because some projects can be adequately managed by a set of hand-
crafted makefiles and shell scripts, it doesn't mean that build automation
tools are bad and should be avoided. They do have their purpose and they do
help a lot. You only need to understand where and when it makes sense to
rely on them, and in what cases it makes more sense to rely on other means.
Rui Maciel
