To CPP or not to CPP...

[mw9]

On MacOS, defining the C preprocessor to be cpp appears to be a sub-optimal choice. When invoked this way it runs with -traditional-cpp. One feature of that, apparently, is that the format of pre-processor directives is somewhat constrained. For example, no indentation.

I see an unwelcome result of this when compiling libpng:

In file included from /usr/include/Availability.h:190:
/usr/include/AvailabilityInternal.h:22938:10: error: unterminated conditional directive
        #if __MAC_OS_X_VERSION_MIN_REQUIRED >= __MAC_10_12
         ^
/usr/include/AvailabilityInternal.h:22867:10: error: unterminated conditional directive
        #if __MAC_OS_X_VERSION_MIN_REQUIRED >= __MAC_10_11_4
         ^
... about 25 similar lines snipped ...

/usr/include/AvailabilityInternal.h:30:2: error: unterminated conditional directive
#ifndef __AVAILABILITY_INTERNAL__
 ^
In file included from ./png.h:397:
In file included from /usr/include/zlib.h:34:
In file included from /usr/include/zconf.h:439:
In file included from /usr/include/unistd.h:72:
In file included from /usr/include/sys/unistd.h:182:
/usr/include/Availability.h:239:2: error: #else without #if
#else
 ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

Despite the errors, the compilation of libpng does complete.

I observe that the variables $GCC, $GPP, and $GXX, and their use in various ./configure stanzas, were introduced into the buildme.sh script as a by-product of this commit: Upgrade ICU to 58.2, necessary collation and build patches. https://github.com/Logitech/slimserver-vendor/commit/cb7e0ad0e28d685c1a699f5aad9e92bfb1347807

I think they were introduced to support some differing FreeBSD build environments.

On MacOS, it seems that either cc -E or gcc -E are appropriate ways of invoking the preprocessor. I suspect that, left to their own devices, the various configure scripts would work this out for themselves. And, possibly, the c-compiler and c++-compiler too ?

So, I think something should be changed, but I'm not clear what. Could @fsbruva comment ?

[fsbruva]

You're right, it was done for FreeBSD, to accomodate other-than-default build config. Since it's a problem on Mac, I'll do a PR to remove the CPP references altogether. I'll also add a warning note regarding the presence of dragons for any FreeBSD users with custom CPP specified in their make.conf.

[fsbruva]

As an aside, the various build scripts do not successfully work out CC and CXX for themselves when gcc/g++ are not the "stock" system compilers. Unless the GCC/GXX declaration is problematic, I disagree with the idea of removing it.

[mherger]

@mw9 - thanks for flagging this issue. I would not have seen this, as I don't compile for macOS any more. It's all there, isn't it? Why did you have to build?

[fsbruva]

As I think about this more (and before I've had a chance to test), perhaps the issue is simply a bad default value for GPP on MacOS. What is the behavior if you declare it as an empty string (the test at line 136 notwithstanding)?

[mw9]

@fsbruva

The thought in my mind is that we have now had two unintended consequences on different “stock” systems as a result of the changes, and that perhaps a less intrusive approach would be preferable.

I was thinking in terms of something along the lines of:

if [ Not using the stock system compilers ]; then
    # Export custom CC, CXX, & CPP variables for the duration of the script
    # These will be picked up by the various ./configure stanzas
    export CC=“My non stock c-compiler”
    export CXX=“My non stock c++-compiler”
    export CPP=“My non stock c-preprocessor”
    echo A suitable message
fi

Or even:

CC=“My c-compiler” CXX=“My c++-compiler” CPP=“My c-preprocessor” ./buildme.sh

That should remove the need to provide the CC="$GCC" CXX="$GXX" CPP="$GPP" stanzas to the various ./configure invocations, as the variables would already be in the environment. “Stock” systems are then simply handled as they always were, and see no change. ./configure would just do its thing. Does this not work ?

On MacOS, with a standard XCode install, both cc & gcc invoke the clang compiler. There may be behavioural difference between the two invocations, I simply don’t know. I think that cc is the “stock” invocation, but I may be wrong,

Setting GPP="" does seem to work on MacOS. But then we will be having CPP= in the ./configure stanzas, which may itself inadvertently break something down the line. So I don’t much like it. :smile:

I haven’t sought to test this approach out in practice. There may be other difficulties that have also arisen of which I am simply not aware. Clearly my approach would have these handled on an “exception” basis, if possible, without intruding on other systems. I don’t pretend to know what is best.

[mw9]

@mherger

I don’t have to build on MacOS, it’s simply orders of magnitude faster than my armel SheevaPlug ! See below for why that is relevant to me.

Are you abandoning MacOS ? Or is it simply that the current builds will run fine on 10.11, 10.12, 10.13 anyway, so you just don’t need to. I assume the latter.

My agenda Although the armel build is working fine, there are far too many build warnings for my (inexperienced) comfort level. In an effort to quieten things down, I’ve set about removing some of the warnings by back-porting a few upstream patches into the build process. That way I hope to restrict the warnings to those that might actually matter. It’s rather quicker to do this on the Mac than on the SheevaPlug !

A very naive approach, no doubt. But them I’m no developer, and I don’t have much experience of these things. I’d rather not resort to the -w flag.

It’s too early to say what the result will be, or whether it would actually be useful. Patching away the warnings does have the benefit that you don't need to see them again.

[fsbruva]

Please forgive my incomprehension. What is the concern about having "all the CPP= in the configure stanzas?" What do you imagine it might inadvertently break and how?

When you tested setting GPP to an empty string, that then passed it as an empty string for CPP throughout the buildme script. This "invalid value" triggered the various configure scripts to check what the compiler recommends/requires. It is the same behavior as if CPP was undefined.

Your comment about armel also confuses me. Does this indicate you're cross-compiling?

In the name of completeness, I will test a modified version of your proposed "export" methodology this week. I should point out that modern FreeBSD only comes with clang/llvm, but doesn't fraudulently pass it off as the GNU c compiler. Therefore, it is not only "custom" build environments that require definition of GCC/GXX, as you contend.

[fsbruva]

Well - given enough time - I now see the elegance and logic of your proposed approach.

Can you please try my patched branch to see if it builds properly on your test machine(s)? In particular, I am interested in MacOS and Debian. Thanks! https://github.com/fsbruva/slimserver-vendor/commit/7ef5559ebe215f1d17905acdbb56e52e198e7f5f

[mw9]

@fsbruva I'll certainly give that a try, but probably not for a week or so. I've been somewhat elsewhere engaged over the last few months.

[fsbruva]

No problem. I don't have access to a MacOS box. I could (and probably should) spool up a Debian virtual machine for testing.

[fsbruva]

@mw9 I have successfully tested my fork on Debian 9.5 (amd64 and i686). Have you had time to test it on Mac OS?