By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,227 Members | 1,290 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,227 IT Pros & Developers. It's quick & easy.

Preference: Header File OR Compile Flags?

P: n/a
Hello all:

I apologize if this query seems a bit off-topic. But I couldn't think
of another place to post my message.

I would like to get an idea of how you all like to handle preprocessor
defines. Do you like to create a header file with all the associated
defines and then include it with every frickin' source file that's
created/modified, OR do you appreciate the ability to pass these on
the command line or from a makefile? Can you tell which method I
prefer?

I have been involved with some discussions on this topic, and though I
have voiced my preference (along with a few reasons to support), I
don't feel like I'm coming up with compelling reason(s) for supporting
my preference. Is this just purely subjective and wreaking of someone
having too much time on their hands? Or is there some strong reasons
for choosing one method or the other?

Thanks, in advance,
Brock
Nov 14 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
[snips]

On Tue, 09 Dec 2003 10:04:28 -0800, Brock wrote:
Hello all:

I apologize if this query seems a bit off-topic. But I couldn't think
of another place to post my message.

I would like to get an idea of how you all like to handle preprocessor
defines. Do you like to create a header file with all the associated
defines and then include it with every frickin' source file that's
created/modified, OR do you appreciate the ability to pass these on
the command line or from a makefile? Can you tell which method I
prefer?


Personally, I prefer a combination of the two.

Suppose I have a header, "porting.h" which contains all my system-specific
defines. Each section would, in turn, be wrapped in something like #ifdef
IS_UNIX ... #endif. Thus, to enable Unix compilation, you'd pass in a
command-line define such as -DIS_UNIX.

Why do I prefer this? Simple: I find including them in a header makes
for maximal readability and maintainability, without sacrificing the
flexibility to use a makefile to select between the options.
Nov 14 '05 #2

P: n/a
In <51**************************@posting.google.com > br******@gentex.com (Brock) writes:
I would like to get an idea of how you all like to handle preprocessor
defines. Do you like to create a header file with all the associated
defines and then include it with every frickin' source file that's
created/modified, OR do you appreciate the ability to pass these on
the command line or from a makefile?


Depending on their actual purpose, some macro defintions belong to the
source code, others to the compiler command line (which basically means
to the makefile).

For example, if you want to define a DEBUG macro, the right place is
the makefile, but the definition of something like MAX_ITEMS belongs to
the source code.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #3

P: n/a
Da*****@cern.ch (Dan Pop) wrote in message news:<br***********@sunnews.cern.ch>...
In <51**************************@posting.google.com > br******@gentex.com (Brock) writes:
I would like to get an idea of how you all like to handle preprocessor
defines. Do you like to create a header file with all the associated
defines and then include it with every frickin' source file that's
created/modified, OR do you appreciate the ability to pass these on
the command line or from a makefile?


Depending on their actual purpose, some macro defintions belong to the
source code, others to the compiler command line (which basically means
to the makefile).

For example, if you want to define a DEBUG macro, the right place is
the makefile, but the definition of something like MAX_ITEMS belongs to
the source code.


And I would say I totally agree with you. But that's the problem I say
that things like a DEBUG macro, or a BOARD_TYPE macro, or a hardware
peripheral-related macro should be in a makefile. I think we agree.
But I can't come up with a strong reason for saying so.
Brock
Nov 14 '05 #4

P: n/a
In <51**************************@posting.google.com > br******@gentex.com (Brock) writes:
Da*****@cern.ch (Dan Pop) wrote in message news:<br***********@sunnews.cern.ch>...
In <51**************************@posting.google.com > br******@gentex.com (Brock) writes:
>I would like to get an idea of how you all like to handle preprocessor
>defines. Do you like to create a header file with all the associated
>defines and then include it with every frickin' source file that's
>created/modified, OR do you appreciate the ability to pass these on
>the command line or from a makefile?


Depending on their actual purpose, some macro defintions belong to the
source code, others to the compiler command line (which basically means
to the makefile).

For example, if you want to define a DEBUG macro, the right place is
the makefile, but the definition of something like MAX_ITEMS belongs to
the source code.


And I would say I totally agree with you. But that's the problem I say
that things like a DEBUG macro, or a BOARD_TYPE macro, or a hardware
peripheral-related macro should be in a makefile. I think we agree.
But I can't come up with a strong reason for saying so.


The strong reason is that you don't want to touch the source code in order
to build the application in a different way and you don't want to put
source code related stuff in the building procedure (i.e. the makefile).

You certainly don't want to look into the makefile in order to understand
the source code or to look into the source code in order to understand
how the application is built.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.