Macro does not reach .c file

Question

I am trying to enable a set of functions from a header only if a macro is defined

I define the macro before including anything and it reaches the .h file and highlights the proper functions, but it does not reach the .c file so I can call the functions with the right prototypes but they have no definition since the .c file does not see I defined the macro

Is there some way to get this to work without having to stuff all of the .c code inside the .h file?

example:

test.h:

#ifdef _ENABLE_
int enabled_function(int a, int b);
#endif

test.c:

#ifdef _ENABLE_
int enabled_function(int a, int b)
{
    return a + b;
}
#endif

main.c:

#define _ENABLE_

#include "test.h"

int main()
{
    printf("%d", enabled_function(10, 10));
}

Answer 1

you need to use conditional compilation in both header and C file

in header file:

#define SOMETHING


#ifdef SOMETHING
int a(int);
int b(int);
int c(int);
#endif

In the C file:

#include "header_file_with_SOMETHING_declaration.h"

#ifdef SOMETHING
int a(int x)
{
    /* ... */
}

int b(int x)
{
    /* ... */
}

int b(int x)
{
    /* ... */
}
#endif

Answer 2

"Is there some way to get this to work without having to stuff all of the .c code inside the .h file?"
and from comments...
"...but I wish to be able to define the macro in my main file and have it be visible from the .c file too

So, you are asking to #include one .c file into another .c file. This is doable with caution. But because a .c file containing the main() function cannot be #include into another .c file without invoking a multiply defined symbol error for main(...), it has to be the other way around. That is a dedicated .c file (eg. enabled.c) could be created that contains all of the #defines function prototypes and definitions. This .c file can then be #included into main.c to hopefully satisfy a variation of what you are looking for.

Following is tested source code that does this:

enable.c

#define _ENABLE_ 

//test criteria - then create prototype of enabled_function
#ifdef _ENABLE_
static int enabled_function(int a, int b);
#endif

#ifdef _ENABLE_
static int enabled_function(int a, int b)
{
    return a + b;
}    
#endif

static int use_enabled_function(int a, int b); 
//This will be created with or without _ENABLE_, but its
//definition changes based on whether _ENABLE_ exists or not. 
static int use_enabled_function(int a, int b)
{
    #ifdef _ENABLE_
    return enabled_function(a, b);
    #elif
    return -1;
    #endif
}    

main.c

#include "enable.c"

int main(void)
{
    //test criteria - then use enabled_function
    #ifdef _ENABLE_ //must include test for existence before using
    printf("%d\n", enabled_function(10, 10));
    #endif
    //no need to test criteria here (tested internally)
    printf("%d\n", use_enabled_function(10, 10));

    return 0;
}        

Answer 3

Your source files test.c and main.c represent separate translation units. The macro definitions declared in one are not visible to the other.

Declarations that need to be visible across multiple translation units, whether of macros or of anything else, generally should go into header files that all translation units wanting them #include. It is possible to have a header that serves the sole purpose of defining macros that control configuration options, that you would create or update prior to compilation. There are tools that automate that sort of thing, but they are probably much heavier than you require for your purposes right now.

For macros specifically, most compilers also offer the option of specifying macro definitions via compiler command-line arguments.

Either way, no, your definition in main.c of macro _ENABLE_ will not be visible in test.c. (And no, you shouldn't merge test.c into test.h.)

But you should also consider whether you actually need any of that. Certainly there are use cases for cross-translation-unit build-time configuration, but what you present does not look like one of them. It is rarely very useful to suppress the compilation of a function just because you know you're not going to call it. it is usually better to either remove it altogether or to leave it, uncalled. In the latter case, your linker might even be smart enough to omit unused functions from the final binary.