CODEWITHSUNDEEP
cgithubgccgnu-toolchain
johnco3
johnco3

Reputation: 2642

customizing the gcc compiler to add a built-in preprocessor macro

I am trying to customize a particular release of gcc (gcc 11.4.0) to make a small change which I need to share with some other developers on github. To this end, I need to fork gcc to add a pre-processor definition (MY_DEFINITION) that gets added to every call (without the user having to specify -DMY_DEFINITION=1 on every invocation. Eventually I would like to share this patch with other upstream developers. With this in mind I need help in 2 areas:

  1. I need help forking gcc to my github account and getting access to the labels so I can make a local branch to add my patches starting from that github branch of gcc. I did the usual thing of selecting the fork option in the official gcc github repo. This correctly forked the repository to my github account, however when I clone this forked repository to my local workspace, I cannot checkout releases/gcc-11.4.0 as all the branch and tag details are not brought along with the forked gcc. I need help with getting access to these release branches locally, and once I do, I need to create a local branch from that point 'my_macro_feature' to add my patches for later upstream release. I'm new to this patching process so advice on how to do this correctly would be greatly appreciated.

  2. Assuming I can do the first step above, which file in gcc contains the builtins for macros. I'm having a hard time finding how I can change this relatively tiny feature.

Upvotes: 0

Views: 73

Answers (1)

spillner
spillner

Reputation: 394

You almost certainly /don't/ want to maintain a separate fork of GCC just to add one standard #define. The preprocessor was in fact designed as a way to manage this kind of configuration without having to update the compiler and/or program source for every small platform change. There are four reasonable options to you; #4 is the one most like what you're looking for above ("X"), but probably the last one a professional developer would select to solve your overall problem ("Y"):

(1) Use a project configuration/build tool (such as make) set to automatically inject the -DMY_DEFINITION=whatever into your compiler arguments. This is a set-once-and-forget-it task (at least per project), and once you've migrated to a build tool (instead of hand-typed gcc commands) you'll get all sorts of other benefits and simplifications.

(2) Require every project that is going to depend on the MY_DEFINITION token to include a particular header file, which then provides the appropriate #define for each build platform. This is the approach that libraries almost always take, so that they don't need to impose any requirements on the build tool (as in (1) above). I assume, though, that if you're asking this question, you've already considered and rejected this option.

(3) As @craig-estey suggests above, generate a mygcc wrapper containing something like

#!/bin/bash
/usr/bin/gcc -DMY_DEFINITION=whatever $*

and compile with that instead of calling gcc directly. You could even call this script gcc and put it somewhere in your $PATH ahead of the system-provided gcc; that way you don't need to remember the separate name.

(4) Insert your definition into one of the automatically-included header files on your platform. You can find out where those are located by creating an empty file (touch foo.c) and invoking GCC with the "-H -E" options: gcc -H -E foo.c. On my system, one such file is /usr/include/stdc-predef.h. You just need to maintain or reinsert your #define MY_DEFINITION ... patch in this file every time GCC is updated, but that's far less work than maintaining and distributing an entirely separate fork. Note that if MY_DEFINITION shadows any standard system #defines, it might be overridden if other system #include files do a later unconditional #define without an #ifndef guard. Test (gcc -E is helpful) to make sure you get the results you expect. If necessary, you might have to maintain a list of patches to those conflicting header files too, but none of this is more work than maintaining an independent GCC fork.

Upvotes: 3

Related Questions