Filename case on macOS

[ivan-m]

In a project I'm working on, I have some directories in the module path consisting solely of capital letters.

When I try and build this project, I get the following warning:

<built-in>:17:10: error:
     warning: non-portable path to file '"dist/build/JBI/autogen/cabal_macros.h"'; specified path differs in case from file name on disk [-Wnonportable-include-path]
#include "dist/build/jbi/autogen/cabal_macros.h"
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         "dist/build/JBI/autogen/cabal_macros.h"
1 warning generated.

(Which I think comes from clang rather than cabal-install itself.)

I also previously had the executable file in src/jbi.hs; this resulted in a GHC error:

src/JBI.hs:11:8: error:
    File name does not match module name:
    Saw: ‘Main’
    Expected: ‘JBI’

I'm not sure if either of these can actually be fixed, or we just have to deal with the joys of caseless filesystems.

cabal-install version 2.0.0.0
compiled using version 2.0.0.2 of the Cabal library

macOS Sierra 10.12.6

[ivan-m]

Oh, and the executable directory was then conflated with the library module path (because of course dist/build/jbi is the same as dist/build/JBI).

[23Skidoo]

So the issue is that Cabal is generating the string #include "dist/build/jbi/autogen/cabal_macros.h" which should be #include "dist/build/JBI/autogen/cabal_macros.h"?

[ivan-m]

Yes

[tfausak]

I am also running into this problem.

    /Users/taylor/Documents/GitHub/rattletrap/<built-in>:15:10: error:
         error: non-portable path to file '".stack-work/dist/x86_64-osx/Cabal-2.0.1.0/build/Rattletrap/autogen/cabal_macros.h"'; specified path differs in case from file name on disk [-Werror,-Wnonportable-include-path]
    #include ".stack-work/dist/x86_64-osx/Cabal-2.0.1.0/build/rattletrap/autogen/cabal_macros.h"
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             ".stack-work/dist/x86_64-osx/Cabal-2.0.1.0/build/Rattletrap/autogen/cabal_macros.h"
    1 error generated.
    `gcc' failed in phase `C pre-processor'. (Exit code: 1)

[newmana]

Is there a way to work around this problem? Or a cause?

The workaround is to remove things like -Werror.

[judah]

I just ran into this (with stack-1.6.1 and Cabal-2.0.1.0 on macOS Sierra 10.12.6) and perhaps tracked down the cause a little further.

Regular output files (for example from the module Some.Module) are put in .../build/Some/Module.hi ; meanwhile autogenerated files (like Paths_* and cabal_macros.h) are put in .../build/{package-name}/autogen/...". Those can overlap (.../build/Some and .../build/{package-name}) if package-name matches a top-level module/directory; this is a little nonhermetic, but doesn't seem to break anything. But they can also overlap on a case-insensitive filesystem if the package is named some, and that causes the error in question.

Ideally we could put .hi and .o files in an unambiguous, separate directory from autogenerated files. I'm not sure if that would break any assumptions within Cabal, though.

[hvr]

@judah fwiw, I think with cabal new-build the layout is different enough to avoid such accidental clashes:

The new-style folders look like

• dist-newstyle/build/${ARCH}/${COMPILER}/${PN}-${PV}/build/autogen/Paths_${PN}.h
• dist-newstyle/build/${ARCH}/${COMPILER}/${PN}-${PV}/build/Paths_${PN}.hi

So I don't see a potential clash between ${PN} and module names, but there might be one with the autogen/ folder, if you had module namespaces like AutoGen.Foo.

This would be easy to workaround, if we renamed autogen/ to e.g. _autogen/; this is dual to your suggestion, which actually sounds sensible as well, and may actually be more future-proof, as there's other files that might get thrown into the build/ folder which could easily case-clash with each other (like executables, or even if you name your executable autogen - c.f. #5044). We could try to move the generated module-named files into sub-folder like e.g.

• dist-newstyle/build/${ARCH}/${COMPILER}/${PN}-${PV}/build/_/Paths_${PN}.hi

[judah]

In case it helps others: I was able to work around this issue somewhat by adding -optP-Wno-nonportable-include-path to the ghc-options for my project.

[gbaz]

related/semi-dup: #783

[sjakobi]

I seem to have run into a variation on this issue at dhall-lang/dhall-haskell@9edbcc4:

In the same project, I have

1. A package dhall-json that contains a module Dhall.Yaml.
2. A package dhall-yaml that contains a module Dhall.YAML and that depends on dhall-json.

(stack) builds on both OS X and Windows failed with

    C:\projects\dhall-haskell\dhall-yaml\src\Dhall\YAML.hs:3:8: error:
        File name does not match module name:
        Saw: `Dhall.YAML'
        Expected: `Dhall.Yaml'
      |
    3 | module Dhall.YAML
      |        ^^^^^^^^^^

I ended up renaming the modules.

[andreasabel]

Me too, with project https://github.com/BNFC/bnfc :

$ cabal build all
Build profile: -w ghc-8.10.3 -O1
In order, the following will be built (use -v for more details):
 - BNFC-2.9.0 (lib:BNFC, exe:bnfc) (configuration changed)
Configuring BNFC-2.9.0...
Preprocessing library for BNFC-2.9.0..
Building library for BNFC-2.9.0..
Preprocessing executable 'bnfc' for BNFC-2.9.0..
Building executable 'bnfc' for BNFC-2.9.0..

<built-in>:15:10: error:
     warning: non-portable path to file '"/Users/abel/project/open-source/bnfc/dist-newstyle/build/x86_64-osx/ghc-8.10.3/BNFC-2.9.0/build/BNFC/autogen/cabal_macros.h"'; specified path differs in case from file name on disk [-Wnonportable-include-path]
#include "/Users/abel/project/open-source/bnfc/dist-newstyle/build/x86_64-osx/ghc-8.10.3/BNFC-2.9.0/build/bnfc/autogen/cabal_macros.h"
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         "/Users/abel/project/open-source/bnfc/dist-newstyle/build/x86_64-osx/ghc-8.10.3/BNFC-2.9.0/build/BNFC/autogen/cabal_macros.h"
1 warning generated.