build on macos (case insensitive filesystem)

changed milestone to %v2506

added community discussion enhancement labels

assigned to @mark

This would be great, as it would save me from creating case-sensitive images/partitions. I am happy to help.

For reference, foam-extend resolved this using the Template suffix, e.g. VectorTemplate.H and Vector.H, similar to your Vector.H -> Vector.T.H suggestion; I personally prefer Template to .T.

Not sure if the case-insensitivity means that the make rules resolve the .C endings as .c and then invoke the c compiler instead of c++.

This does not seem to be an issue in foam-extend, which still uses the .C extension.

Philip beat me to it on foam-extend

The reason we went with the .T pre-suffix with our port for Windows, was due to the max path limit on Windows of 256 characters + 3 for drive + 1 for 0 byte, i.e. 260 MAX_PATH, in an attempt to minimize its impact during builds. There are tricks to work around this, either through experimental Windows flags or by adjusting all build scripts to account for the UNC paths, albeit not all GNU GCC build binaries work well with UNC.

The other reason is that it's easier to reverse the change, since we stay in sync with the upstream versions. Given that (I have a vague idea of) there already being at least one file in OpenFOAM having Template in the name...

The compilation should use the c++ compiler for .C, but there is always a possibility of using c++ with a real .c in case it is somehow picked up. In other words, the build script states vector.C but if the file is really named vector.c in the file system, then c++ is still used since it's what the script stated.

Here are the lists for files we filter for, including enabling swak4Foam to work with it:

Black-list for files to not automatically rename, using standard grep regex:

OSspecific.H
^USERD_.*\.[CHhc]
^PV3.*
^PV4.*
^STL.*
^Ergun_.*\.[CH]
^SpaldingsLaw\.[CH]
^[A-Z][A-Z0-9][A-Z0-9]*.*\.[CH]
^CarnahanStarling[A-Z].*\.[CH]
^Ergun.*\.[CH]
^Gibilaro\.[CH]
^Gidaspow[A-Z].*\.[CH]
^HrenyaSinclair[A-Z].*\.[CH]
^JohnsonJackson[A-Z].*\.[CH]
^Lun[A-Z].*\.[CH]
^Schaeffer[A-Z].*\.[CH]
^SchillerNaumann[A-Z].*\.[CH]
^SinclairJackson[A-Z].*\.[CH]
^Syamlal[A-Z].*\.[CH]
^WenYu.*\.[CH]
^CrankNicholson.*\.[CH]
^CourantNo\.[CH]
^C\.[CH]
^CaCO3\.[CH]
^Ar\.[CH]
^ArI\.H
^Arrhenius.*\.[CH]
^BirdCarreau.*\.[CH]
^CrossPowerLaw.*\.[CH]
^HerschelBulkley.*\.[CH]
^Newtonian.*\.[CH]
^SpalartAllmaras.*\.[CH]
^PrandtlDelta.*\.[CH]
^FlexLexer\.h
^FilterFunctionObjectTemplate\.[CH]
^IOfunctionObjectTemplate\.H
^MSwindows\.[CH]
^Test-.*\.[CH]
^[A-Z].*\.txt
^[A-Z].*\.TXT
^[A-Z].*\.unv
^[A-Z].*\.msh
^README.*
^COPYING.*
^IDEA.*
^TECIO.*
^MASTER.*
^GLOBAL.*
^CGAL.*
^OFversion_template\.rc
^Python\.H

File which are white-listed, namely forcefully renamed:

^fvcDDt\.[CH]
^char\.H
^string\.H
^wchar\.H
^ode\.[CH]
^face\.H
^point\.H
^debug.*\.[CH]
^error\.[CH]
^token\.[CH]
^typeInfo\.[CH]
^MeshObjects.*\.[CH]
^Time.*\.[CH]
^Swap.*\.[CH]
^metis.*\.[CH]
^parMetis.*\.[CH]
^scotch.*\.[CH]
^ptscotch.*\.[CH]
^zoltan.*\.[CH]

Well, with a few white-list exceptions:

^Function1Template\.[CH]
.*ChemistryReductionMethods.*\.C
.*ChemistryTabulationMethods.*\.C
.*ChemistrySolvers.*\.C

Here is the snippet of bash code we use to whitelist files that are expected to be template files:

find applications src -name "[A-Z]*.H" -type f | \
while read line
do
    line_name=${line##*/};
    line_name=${line_name%.H};
    if grep -q -Pzo 'template.*\n.*class.*'$line_name $line
    then
        echo "^$line_name.*\.[CHch]"

    elif [ $(awk '/template$/,/class '$line_name'/' $line | wc -l) -gt 0 ]
    then
        echo "^$line_name.*\.[CHch]"

    elif grep -q NoRepository $line
    then
        echo "^$line_name.*\.[CHch]"

    fi
done

Thanks @wyldckat - The list of whitelisted files is good information. I'd cleanly forgotten about time.h versus "Time.H" and that our namings for scotch headers (for example) will collide with the scotch headers themselves.

The point about 256 path limits on Windows is also good to remember.

@mark This would indeed facilitate macOS builds.

Not sure if the case-insensitivity means that the make rules resolve the .C endings as .c and then invoke the c compiler instead of c++.

AFAIK Make itself is always case-sensitive, so I don't think this will be an issue.

Some of these issues will be similar to what @wyldckat experienced with his Window port. Many of the conflicts from template files were resolved by renaming template files (eg, Vector.H -> Vector.T.H). Could work here, but not really sold on the naming convention.

Just out of curiosity, would these changes involve changing the class (template) names too? Would the file/class name changes imply a breaking change for third-party packages?

For the others in the MacOS world ( @alexey, @gerlero, @philipc, etc) - has anyone already started working on this, or even just thought about good ways to tackle it?

Haven't thought much of it more than the fact that it would be interesting; this given that making such a change on macOS only would immediately break compatibility with third-party packages.

@mark Unfortunately, I have only bad way ;) Once I have tried to convert files into:

snake-case file names;
hpp/cpp/ipp file extensions.

The initial part was rapid, but then I imagined how much effort should be put into maintaining compatibility with the main branch and abandoned the project.

With APFS I do not see a problem with case-sensitive partition. It is easy to create, it mounts automatically, disk space is shared between the root volume and OpenFOAM sub-volume.

This will get pushed back a bit. There are indeed quite a few more things to break for people's existing code than seems immediately responsible (eg, rename Time.H to foam_time.H or Time.hxx, since it would otherwise conflict with the system time.h). And as @alexey said, not as critical with APFS now.

In any case, to make life easier, the develop branch now has a convenient way to configure using homebrew. For example,

bin/tools/foamConfigurePaths -fftw-brew -scotch-brew

On the assumption that this can be really convenient, can also handle a large pre-selection in one go:

bin/tools/foamConfigurePaths -with-homebrew

The resulting edited files looks something like this:

#------------------------------------------------------------------------------
# USER EDITABLE PART: Changes made here may be lost with the next upgrade

fftw_version=fftw-system
export FFTW_ARCH_PATH="$(brew --prefix fftw 2>/dev/null)"

# END OF (NORMAL) USER EDITABLE PART
#------------------------------------------------------------------------------

Additionally, for people who prefer to use gcc from homebrew, it will stop automatically dropping back to clang, but only if you take the trouble to specify which gcc version is to be used.

For example, in the etc/prefs.sh file:

export WM_COMPILE_CONTROL="version=14"

Then

$ wmake -show-path-cxx
/opt/homebrew/bin/g++-14

Added in some hacky changes to OSspecific so that it will symlink in the FlexLexer.h when compiling with Gcc on MacOS (otherwise the compiler doesn't want to search in the proper system paths).

There are also some weird configs like trying to use homebrew CGAL with the system clang compiler. For those, will also need to use foamConfigurePaths -gmp-brew -mpfr-brew as well.

Still not all perfect, but at least something and less fiddling than before.

build on macos (case insensitive filesystem)

Direct name clashes

Symlink name clashes

Name masking

Other considerations

Child items

Activity

Admin message

build on macos (case insensitive filesystem)

Direct name clashes

Symlink name clashes

Name masking

Other considerations

Child items

Linked items

Related merge requests

Activity