Use bsdstrings.h instead of strings.h and document the header renames/deletions

[ryandesign]

I am trying to use Retro68 to compile a third-party library for use in my project, and it failed when that third-party library included string.h, which wants to include strings.h (under some conditions which were true in this case):

#if __BSD_VISIBLE
#include <strings.h>
#endif

But interfaces-and-libraries.sh has renamed strings.h to bsdstrings.h so as not to conflict with Strings.h on my Mac's case-insensitive filesystem:

function removeConflictingHeaders()
{
    # On case-insensitive file systems, there will be some conflicts with
    # newlib. For now, universal interfaces get the right of way.
    rm -f "$1/Threads.h"        # thread.h: does not currently work anyways
    rm -f "$1/Memory.h"         # memory.h: non-standard aliasof string.h
    cp "$1/strings.h" "$1/bsdstrings.h"
    rm -f "$1/Strings.h"        # strings.h: traditional bsd string functions
}

There are also several places where the third-party library includes strings.h directly which I now realize I will need to change to bsdstrings.h

It seems like Retro68 should modify the string.h that it ships so that it includes bsdstrings.h instead of strings.h. I don't know whether this change should be made directly to the bundled gcc files (which might make updating the bundled gcc to a newer version more difficult) or whether a separate patch system exists or should be created.

You should also document in the readme (or is there other documentation?) that you must use bsdstrings.h instead of strings.h, that you should use string.h instead of memory.h, and that you cannot use threads.h.

I wonder whether giving the universal interfaces the right of way was the correct choice. It seems to me like Retro68 is primarily for creating new Mac OS software. As such, it wouldn't be difficult for the developer of such new software to include, say, MacStrings.h instead of Strings.h to avoid the conflict. Such new software might very well want to use third-party libraries that have no knowledge of Retro68's header renaming and it is desirable not to have to maintain a set of patches for such third-party libraries. Yet I realize Retro68 has been around for awhile and changing it now could disrupt existing projects that use it.

Of course all these problems go away on case-sensitive filesystems but it is not convenient to impose such a requirement on Mac users since Macs use case-insensitive filesystems by default. Erasing and reinstalling one's system is a heavy requirement for using a software package, and some other Mac software packages do not work on case-sensitive file systems and their vendors don't support using a case-sensitive filesystem since it is so uncommon on Macs.

[autc04]

You are probably right in that preference should have been give to the BSD headers.

I am also now thinking - maybe the headers could be patched with some preprocessor magic to

• make a reasonable guess about whether the user is getting the header they want and issue a #warning otherwise (such as when BSD strings are included when various Apple-specific macros are defined, i.e. after Apple headers).
• just include both files when the user doesn't say what they want

Another problem with the current setup is that the rms only happen on case-insensitive filesystems, so different people will need different patches.

Suggestions and opinions are welcome.

[ryandesign]

Another problem with the current setup is that the rms only happen on case-insensitive filesystems, so different people will need different patches.

Yes, and as I was working on adding Retro68 to MacPorts (where our build machines use case-sensitive filesystems but most of our users don't) I changed it so the rms always happen.