My recent patch regarding the postgresql headers location problem as triggered a short thread on xemacs-review on the way to achieve the desired effect. In short, there are currently two different tricks used in XEmacs for including headers which location is not fixed: the Athena trick and the Sound trick. I'm in favor of the Athena trick while Martin is in favor of the Sound trick. However, the more I think about it, the more I dislike Martin's solution. I'd like to have more opinions on this. Assume you have to include some foo headers which location might change from system to system. With an agreement on the idea of not polluting all command lines with random -I flags, here are the two ways XEmacs currently handles this: The Athena trick ================ In short, define a macro FOO_INCLUDE which would expand this: | #include FOO_INCLUDE(file) => #include <path/to/foo/file> The following code appears in XEmacs: ,---- | /* For use in #include statements. | You can't use macros directly within the <> of a #include statement. | The multiply nested macros are necessary to make old gcc's happy. | However, those nested macros are too much for AIX xlc to deal with. */ | #if defined(_AIX) && !defined(__GNUC__) | #define ATHENA_INCLUDE(header_file) <ATHENA_H_PATH/header_file> | #else | #define INCLUDE_GLUE_2(dirname,basename) <##dirname##/##basename##> | #define INCLUDE_GLUE_1(dirname,basename) INCLUDE_GLUE_2(dirname,basename) | #define ATHENA_INCLUDE(header_file) INCLUDE_GLUE_1(ATHENA_H_PATH,header_file) | #endif `----- The Sound trick =============== In short, for each file that needs such a header, rewrite its compilation rule in order to add the proper -I flag. The following code appears in XEmacs: ,---- | #ifdef HAVE_NATIVE_SOUND | sound_cflags=＠sound_cflags＠ | #endif | | ... | | #ifdef HAVE_NATIVE_SOUND | sunplay.o: ${srcdir}/sunplay.c | $(CC) -c $(sound_cflags) $(cflags) ${srcdir}/sunplay.c | hpplay.o: ${srcdir}/hpplay.c | $(CC) -c -Demacs $(sound_cflags) $(cflags) ${srcdir}/hpplay.c | #endif /* HAVE_NATIVE_SOUND */ `----- Here are the pros and cons _I_ see in both solutions. Let me say again that I'm *strongly* in favor of the Athena trick. The Athena trick ================ Pros: ----- * It can be easily generalized (that's what I did in my patch): globally define the GLUE macros, define a new FOO_INCLUDE each time it is needed, and use it for the concerned headers. * You don't need to add random -I flags anywhere. * When a new file suddenly needs such a header, there's nothing special to do, just be aware that the inclusion macro must be used. Cons: ----- * The GLUE macros are ugly, but this not our fault. * Each time a new inclusion macro needs to be written, you have to redo the AIX test. I concede that this is not very satisfactory. The Sound trick =============== Pros: ----- * People don't have to be aware of any inclusion macro, just #include the concerned file. Cons: ----- * Each time a new header location problem is encountered, you have to add special code in Makefile.in.in for each file requiring the header. * This code duplicates the normal compilation rule, which means that if one day the rule has to be changed, you have to remember to do the same change in all special cases that were added. * When a single file depends on several features that might or might not be present, the Makefile.in.in hackery will increase in complexity. * The position (in the command line) where the -I flag will be added *is* relevant. For instance: - if you put it first (this is currently the case for the sound support), it will appear *before* -I., hence the risk of including the wrong config.h file. This just happened to me as my postgresql header directory contains one such config.h file. - if you put it last, you take the risk of including wrong headers of the same name that could be present in the other include directives. - any other place (the best one would be after -I. and before anything else) will require even more trickery in Makefile.in.in as you can't use $cflags anymore. That's the current situation, as I see it. I'd like to harmonize the way it's done for the existing cases, but also in order to make our life easier in future situations. I'll follow what the majority thinks, if enough people care to express their opinion. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99