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

[Charles Wilson]

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() {
  ....
}

#if defined(PACKAGE_FOO_TESTING)
int main(int argc, char *argv[])
{
  ....
}
#endif
----

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

#if !defined(PACKAGE_FOO_TESTING)
# define BUILDING_LIBUTIL
#endif

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 Makefile.am, 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
regardless).

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).

--
Chuck