another macro include question

Discussion in 'C Programming' started by sinbad, Mar 31, 2009.

  1. sinbad

    sinbad Guest

    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

    now the problem is since common.o is already generated while 1.c is
    For 2.c "gnu make" is not recompiling common.c to generate the new
    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);
    sinbad, Mar 31, 2009
    1. Advertisements

  2. 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.
    Kenny McCormack, Mar 31, 2009
    1. Advertisements

  3. 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
    Jens Thoms Toerring, Mar 31, 2009
  4. ------------------------(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
    Pascal J. Bourguignon, Mar 31, 2009
  5. 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.
    Kenny McCormack, Mar 31, 2009
  6. sinbad

    jacob navia Guest

    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.
    jacob navia, Mar 31, 2009
  7. sinbad

    Thad Smith Guest

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

    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.
    Thad Smith, Mar 31, 2009
  8. 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.
    Kenny McCormack, Apr 1, 2009
  9. 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

    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 and answered from here).

    Finally, do we need to dump the C sources of make onto the newsgroup
    to make make discussion on topic?
    Pascal J. Bourguignon, Apr 1, 2009
  10. sinbad

    luserXtrog Guest

    And I'm an Humunculus!
    luserXtrog, Apr 1, 2009
  11. Even if you always put bacon on your salad and would find it more
    convenient if he did.
    lawrence.jones, Apr 1, 2009
  12. sinbad

    Lionel B Guest

    And there's a butcher's next door.
    Lionel B, Apr 3, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.