[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tests: import variables for MSVC.

From: Charles Wilson
Subject: Re: [PATCH] tests: import variables for MSVC.
Date: Sat, 25 Sep 2010 00:32:41 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

On 9/24/2010 8:13 PM, Roumen Petrov wrote:
> About pre-processor flags - better is C code to start with #define
> BUIILD_FOO instead -DBUIILD_FOO in makefile.

No, actually, it is not better.  The reason is, any given C file *might*
be used in a library, or it *might* be used in an application -- or
both, depending on compile flags.  For instance, suppose you have a
utility library, where each function has a built-in self test:

int some_util_function() {

int main(int argc, char *argv[])

You wouldn't want to unconditionally define BUILDING_LIBUTIL in this
case.  Now, certainly, you could do some magic like


but...(a) this is a deliberately simple example, and (b) there's a
better way.

There is *one place* in the package where you KNOW which files are being
compiled for inclusion in a library, and which are not: and that's the
Makefile (or, or cmakefiles.list, or whatever) -- NOT the C
code itself.  Why should you duplicate that knowledge in the source code
itself?  What happens when you refactor a "big" library into multiple,
smaller libraries?  With the Makefile approach, you simply reassign when
.c's go with which libfoo_SOURCES, and each libfoo_la_CFLAGS has a
different -DBUILDING_*  -- and you don't have to modify any of the .c's
at all (you'd have to modify some .h's, but you'd need to do THAT

Your way, this refactoring requires coupled changes in each and every .c
file -- because you put "knowledge" (about which library each .c file
belongs to -- inside each .c file itself, and that's the wrong place for
that knowledge. It *belongs* in the buildsystem (e.g. the Makefile).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]