Yes those files should exist for other build systems then
hadrian, i.e. for `libffi-clib` to be "real Cabal package". E.g.
`cabal-install` doesnt ever execute autoconf tools by itself.
Those changes are done by GHCs ./configure script, and I find it
kind of annoying that also e.g. `libraries/unix/config.sub`
changes, but I have looked at
modified: libraries/unix (modified content)
for as long as I remember contributing to GHC, and I think this is
just an inherent limitation of the tools used. These files have to
be (re)generated in-tree, which is very bad, but apparently there
is no proper way to do it.
I'd say this is the same issue as generating `base.cabal` in-tree
(from `base.cabal.in`). This is just wrong, given the most build
artifacts are in `_build/`. It would be great if source tree could
be immutable during the build, but I don't see that ever be a
priority.
- Oleg
After building GHC, and then doing `git status` I get
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
(commit or discard the untracked or modified content in submodules)
modified: libraries/libffi-clib (modified content, untracked content)
I have never so much as cd'd into lifff-clib! Doing `git status` in there gives
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: aclocal.m4
modified: fficonfig.h.in
I can show the diffs if you like but some are like-/* The size of 'double', as computed by sizeof. */
+/* The size of `double', as computed by sizeof. */
Others are like-# Copyright (C) 2003-2025 Free Software Foundation, Inc.
+# Copyright (C) 2003-2018 Free Software Foundation, Inc.
Should these files be in the repo at all?
Should I open a ticket?
Simon
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org