another macro include question

[sinbad]

there is a source file "common.c" which will get linked with different
modules.the code in common.c will look like this.

common.c
--------

#ifdef FEAT_ENABLE

/* function_set_1*/

#else

/* function_set_2*/

#endif

common.c will get linked with two independent modules (1.c and 2.c).
FEAT_ENABLE is defined for 1.c and not for 2.c.

now common.o will get generated while compiling for 1.c.
since FEAT_ENABLE is defined for 1.c, common.o now contains
function_set_1.

now the problem is since common.o is already generated while 1.c is
compiled,
For 2.c "gnu make" is not recompiling common.c to generate the new
common.o
which should contain function_set_2 (which is suppose to be the
desired result);

what can be done for this, i want common.c to always be compiled for
each module(1.c,2.c);

 

[Kenny McCormack]

there is a source file "common.c" which will get linked with different
modules.the code in common.c will look like this. ....
what can be done for this, i want common.c to always be compiled for
each module(1.c,2.c);

First of all, and to get this out of the way, so the CLC regs can now
roll over and comfortably go back to sleep, is the obligatory:

Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

OK, now that we have that out of the way...

Your question has to do with make, not with C or include files. You
need to do a "rm -f common.o" at some point before the compile step, to
ensure that it is built every time.

There may be, of course, more elegant solutions, which involve somehow
making whatever process determines which module is being built be in the
dependency chain for common.o.

 

[Jens Thoms Toerring]

there is a source file "common.c" which will get linked with different
modules.the code in common.c will look like this.

#ifdef FEAT_ENABLE

/* function_set_1*/

/* function_set_2*/

common.c will get linked with two independent modules (1.c and 2.c).
FEAT_ENABLE is defined for 1.c and not for 2.c.

now common.o will get generated while compiling for 1.c.
since FEAT_ENABLE is defined for 1.c, common.o now contains
function_set_1.

now the problem is since common.o is already generated while 1.c is
compiled,
For 2.c "gnu make" is not recompiling common.c to generate the new
common.o
which should contain function_set_2 (which is suppose to be the
desired result);

what can be done for this, i want common.c to always be compiled for
each module(1.c,2.c);

Change your Makefile to always recompile common.c even if common.o
already exists. make oly checks if common.o is newer or older than
common.c but not if there some macros in common.c that might make
recompiling seem to be be useful. And there's nothing you can do
from the C side about that. The alternative would be to split the
file common.c up into two files, common1.c and common2.c, and link
with common1.o when making an executable out of 1.c and with
common2.o for 2.c.
Regards, Jens

 

[Pascal J. Bourguignon]

there is a source file "common.c" which will get linked with different
modules.the code in common.c will look like this.

common.c
--------

#ifdef FEAT_ENABLE

/* function_set_1*/

#else

/* function_set_2*/

#endif

common.c will get linked with two independent modules (1.c and 2.c).
FEAT_ENABLE is defined for 1.c and not for 2.c.

now common.o will get generated while compiling for 1.c.
since FEAT_ENABLE is defined for 1.c, common.o now contains
function_set_1.

now the problem is since common.o is already generated while 1.c is
compiled,
For 2.c "gnu make" is not recompiling common.c to generate the new
common.o
which should contain function_set_2 (which is suppose to be the
desired result);

what can be done for this, i want common.c to always be compiled for
each module(1.c,2.c);

------------------------(Makefile)--------------------
all: module1 module2


common_1.o: common.c
gcc -DFEAT_ENABLE -c -o common_1.o common.c

module1.o: module1.c common.h
gcc -DFEAT_ENABLE -c -o module1.o module1.c

module1: module1.o common_1.o
ld -o module1 module1.o common_1.o


common_2.o: common.c
gcc -UFEAT_ENABLE -c -o common_2.o common.c

module2.o: module2.c common.h
gcc -UFEAT_ENABLE -c -o module1.o module1.c

module2: module2.o common_2.o
ld -o module2 module2.o common_2.o

 

[Kenny McCormack]

------------------------(Makefile)--------------------
all: module1 module2

etc.

You see what is going on here? Since I managed to get in first, to
point out how "off-topic" this is, now all the semi-regs are falling
over themselves giving answers. Funny, isn't it?

Which demonstrates that there really is no substance to it; it is just
cliques. Whatever clique A is doing, clique B does the opposite.

 

[jacob navia]

etc.

You see what is going on here? Since I managed to get in first, to
point out how "off-topic" this is, now all the semi-regs are falling
over themselves giving answers. Funny, isn't it?

Which demonstrates that there really is no substance to it; it is just
cliques. Whatever clique A is doing, clique B does the opposite.

I have tried to avoid this. For instance I used CB Falconer ggets
in another thread. It is important to discuss according to the
subject matter and not make cliques, even if obviously I think that
heathfield and co ARE a clique.

 

[Thad Smith]

there is a source file "common.c" which will get linked with different
modules.the code in common.c will look like this.

common.c
--------

#ifdef FEAT_ENABLE

/* function_set_1*/

#else

/* function_set_2*/

#endif

common.c will get linked with two independent modules (1.c and 2.c).
FEAT_ENABLE is defined for 1.c and not for 2.c.

now common.o will get generated while compiling for 1.c.
since FEAT_ENABLE is defined for 1.c, common.o now contains
function_set_1.

This isn't a C language issue, but comes up in the course of building C
programs.

It sounds as if you are describing two different target executables, one
defining FEAT_ENABLE, another not. There are several ways to address
this issue.

The cleanest in my mind is to place the intermediate objects in
different directories. You might have one source directory and a build
directory for each version. You could put the separate makefiles or
equivalent in the respective build directories or have the makefiles /
build scripts put intermediates in a particular directory determined by
the build version.

You then may have an "all" makefile target or script to generate all of
the individual versions.

 

[Kenny McCormack]

I'm puzzled - there are on-topic solutions to the OP's problem, so whats
/your/ problem with those being posted?

You're so funny. You're so cute.

Since when has "make" been on-topic?

"make" has classically been one of the major targets of the regs when
bashing newbies for their off-topicness. "make" and, for that matter,
anything toolkit or toolchain related. Obviously off-topic.

 

[Pascal J. Bourguignon]

You're so funny. You're so cute.

Since when has "make" been on-topic?

"make" has classically been one of the major targets of the regs when
bashing newbies for their off-topicness. "make" and, for that matter,
anything toolkit or toolchain related. Obviously off-topic.

Perhaps you might notice that it is cross posted. Perhaps make is of
no concern in compl.lang.c, but the usage of gcc is definitely
on-topic on gnu.gcc.help.

Besides, given that the C standard leaves out to the implementations
and environments software construction, it's natural that questions
about the construction of software programmed in C be answered out of
the C standard. I'd still consider that to be on topic for a
comp.lang.c newsgroup (but I must confess I didn't read the charter of
that newsgroup, I was reading gnu.gcc.help and answered from here).


Finally, do we need to dump the C sources of make onto the newsgroup
to make make discussion on topic?

 

[luserXtrog]

I have tried to avoid this. For instance I used CB Falconer ggets
in another thread. It is important to discuss according to the
subject matter and not make cliques, even if obviously I think that
heathfield and co ARE a clique.

And I'm an Humunculus!
BWaaahahaha-ha!

 

[lawrence.jones]

People who disregard the topic of the group tend to run out of
welcome quite quickly, but this is not cliquiness, any more than it
is cliquiness when your greengrocer gets tired of telling you he
doesn't sell bacon.

Even if you always put bacon on your salad and would find it more
convenient if he did.

 

[Lionel B]

Even if you always put bacon on your salad and would find it more
convenient if he did.

And there's a butcher's next door.