Remove --cabal-file option

[andreabedini]

Closes: #8395

---

Please read Github PR Conventions and then fill in one of these two templates.

---

Template Α: This PR modifies cabal behaviour

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.

Bonus points for added automated tests!

---

Template Β: This PR does not modify cabal behaviour (documentation, tests, refactoring, etc.)

Include the following checklist in your PR:

• Patches conform to the coding conventions.

[andreabedini]

-Documentation created: ../setup-external.dist/work/mylib/dist/doc/html/mylib/index.html
+Documentation created: ../setup-external.dist/work/mylib/dist/doc/html/mylib/

I am running into this annoying problem 🤔 😒

[ulysses4ever]

I am running into this annoying problem thinking unamused

It was recently changed in #8919 (see how it updated the tests). Not sure what to do about it though.

[ulysses4ever]

We could tag the author of that PR maybe.

[andreabedini]

What's puzzling is that it seems to depend on the GHC version 🤔 Let me reset those changes first.

[ulysses4ever]

It may have to do with the version of Haddock (distributed with GHC, so, by extension, on the version of GHC). But yeah, I have no idea really.

[andreabedini]

Maybe I was just mixing up two different failures.

[andreabedini]

Can any Windows expert help me understand what's going on here https://github.com/haskell/cabal/actions/runs/5584068207/jobs/10205063977#step:18:1658?

[gbaz]

might be sporadic, triggered a rerun

[Mikolaj]

Let me try to rerun once again. :)

[andreabedini]

Thanks. I am at loss with what is happening on Windows :-/ I don't think I can do much.

[jasagredo]

I'm able to reproduce the error in 9.4.4:

Running: "C:\ghcup\ghc\9.4.4\lib\../mingw/bin\llvm-ar.exe" "-qL" "..\setup-internal.dist\work\Includes2\dist\build\Includes2-0.1.0.0-mylib+JA8sqakdQMC7oNcBYWFaHI\objs-7580\libHSIncludes2-0.1.0.0-mylib+JA8sqakdQMC7oNcBYWFaHI.a" "@..\setup-internal.dist\work\Includes2\dist\build\Includes2-0.1.0.0-mylib+JA8sqakdQMC7oNcBYWFaHI\objs-7580\ar58B.rsp"
C:\ghcup\ghc\9.4.4\lib\../mingw/bin/llvm-ar.exe: warning: creating ..\setup-internal.dist\work\Includes2\dist\build\Includes2-0.1.0.0-mylib+JA8sqakdQMC7oNcBYWFaHI\objs-7580\libHSIncludes2-0.1.0.0-mylib+JA8sqakdQMC7oNcBYWFaHI.a
C:\ghcup\ghc\9.4.4\lib\../mingw/bin/llvm-ar.exe: error: ..\setup-internal.dist\work\Includes2\dist\build\Includes2-0.1.0.0-mylib+JA8sqakdQMC7oNcBYWFaHI\objs-7580\libHSIncludes2-0.1.0.0-mylib+JA8sqakdQMC7oNcBYWFaHI.a: No such file or directory

It seems the folder doesn't exist. I can confirm that llvm-ar.exe cannot create directories:

Javier@DESKTOP-JDT20GG MINGW64 ~/code/cabal
$ /c/ghcup/ghc/9.4.4/mingw/bin/llvm-ar qL xx/a.a
C:\ghcup\ghc\9.4.4\mingw\bin/llvm-ar.exe: warning: creating xx/a.a
C:\ghcup\ghc\9.4.4\mingw\bin/llvm-ar.exe: error: xx/a.a: No such file or directory

Javier@DESKTOP-JDT20GG MINGW64 ~/code/cabal
$ mkdir xx

Javier@DESKTOP-JDT20GG MINGW64 ~/code/cabal
$ /c/ghcup/ghc/9.4.4/mingw/bin/llvm-ar qL xx/a.a
C:\ghcup\ghc\9.4.4\mingw\bin/llvm-ar.exe: warning: creating xx/a.a

Javier@DESKTOP-JDT20GG MINGW64 ~/code/cabal
$ ls xx
a.a

However, the test passes with GHC 9.6.3, and the behavior of llvm-ar.exe is the same:

Javier@DESKTOP-JDT20GG MINGW64 ~/code/cabal
$ /c/ghcup/ghc/9.6.3/mingw/bin/llvm-ar qL yy/a.a
C:/ghcup/ghc/9.6.3/mingw/bin/llvm-ar.exe: warning: creating yy/a.a
C:/ghcup/ghc/9.6.3/mingw/bin/llvm-ar.exe: error: yy/a.a: No such file or directory

Which makes me think that GHC changed something in the steps it followed for creating the paths.

Confirmed it works also on GHC-9.6.1, so the failure is on 9.4.4

[jasagredo]

Note that MinGW does not understand symlinks, so the test would need to be reworked around this fact (or skipped in windows)

What I mean by this is that the symlinks you have in the Includes2 folder will not work on MinGW on Windows. I had to manually replace them with actual copies of the directories for the tests to run. I don't understand how they can run in GHA (perhaps Git bash?)

[jasagredo]

So in fact it has nothing to do with directories but rather with long paths, and it was fixed in 9.4.5:

• https://gitlab.haskell.org/ghc/ghc/-/issues/21293
• llvm-ar fails to handle long paths on Windows llvm/llvm-project#54559 (in particular this comment by Ryan llvm-ar fails to handle long paths on Windows llvm/llvm-project#54559 (comment))
• https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9683

$ /c/ghcup/ghc/9.4.5/mingw/bin/llvm-ar --version
LLVM (http://llvm.org/):
  LLVM version 14.0.6
  Optimized build.
  Default target: x86_64-w64-windows-gnu
  Host CPU: znver3

Rebasing on top of master should fix this

To confirm this, I shortened the length of the package and sub libraries to 1 letter only and then progressively add letters to --builddir and indeed it worked until I reached abc...m 😁

[andreabedini]

And indeed it works! Thank you again ❤️

[andreabedini]

@ulysses4ever @Mikolaj gentle ping for a review ☺️

[Mikolaj]

Thanks a lot for the tests! How about a changelog?

[ulysses4ever]

LGTM, thank you. And sorry for long delay.

The flag is still available in the library and perhaps v1-commands? There're setup-tests that you updated to not use the flag, but is it really unavailable in setup-tests or is it out of a desire to avoid the legacy flag?

[andreabedini]

The flag is still available in the library and perhaps v1-commands?

It is still available in v1-configure and in ./Setup.hs

~/code/cabal andrea/remove-cabal-file
❯ cabal run -- cabal v1-configure --help | grep cabal-file
 --cabal-file=PATH              use this Cabal file

~/code/cabal andrea/remove-cabal-file
❯ cabal run -- cabal act-as-setup --build-type Simple -- configure --help | grep cabal-file
Warning: this is a debug build of cabal-install with assertions enabled.
 --cabal-file=PATH              use this Cabal file

There're setup-tests that you updated to not use the flag, but is it really unavailable in setup-tests or is it out of a desire to avoid the legacy flag?

🤔 uhm, TBH, I don't remember what I was thinking 5 months ago 😂 yes, perhaps I could have kept the tests the same, but if there is a way to run the tests without "internal" options perhaps that is the better way to go.

[ulysses4ever]

That is fair and I agree. Is there no place in the docs to expand a little bit on the "internal" nature of this flag? I remember users trying to use the flag in all sorts of wrong ways...

[ulysses4ever]

And not only that but just improve its docs.

[andreabedini]

That is fair and I agree. Is there no place in the docs to expand a little bit on the "internal" nature of this flag? I remember users trying to use the flag in all sorts of wrong ways...

There is space but I am afraid someone else will have to do this. I don't know much about that flag; only from reading #8395 I thought it was a low-hanging fruit ☺️ and here we are half a year later 😂

[Mikolaj]

That is fair and I agree. Is there no place in the docs to expand a little bit on the "internal" nature of this flag? I remember users trying to use the flag in all sorts of wrong ways...

There is space but I am afraid someone else will have to do this. I don't know much about that flag; only from reading #8395 I thought it was a low-hanging fruit ☺️ and here we are half a year later 😂

Could you open a short ticket about it and mark it documentation? Thank you.

I still don't see a changelog file. Am I missing it?

[Mikolaj]

Alternatively, perhaps let's not close #8395 and let's add the note about the docs there.

[andreabedini]

@Mikolaj I have added the changelog ;-)

[Mikolaj]

This looks fine. Thank you.