Repository navigation
Make the directory layout match upstream MSYS #16
Description
Activity
- added this to the First release of Git for Windows generated using the new SDK milestone
on Oct 15, 2014 👍
It would be enough for that
profile.xmlto lose its<system-map>section, yes? I.e.<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <profile project="MinGW" application="mingw-get"> <repository uri="http://prdownloads.sourceforge.net/mingw/%F.xml.lzma?download"> </repository> <repository uri="https://github.com/git-for-windows/sdk-packages/blob/master/%F.xml.lzma?raw=true"> <package-list catalogue="git-win-sdk-package-list" /> </repository> <system-map id="default"> <sysroot subsystem="mingw32" path="%R" /> <sysroot subsystem="msys" path="%R/../" /> </system-map> </profile>
would become
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <profile project="MinGW" application="mingw-get"> <repository uri="http://prdownloads.sourceforge.net/mingw/%F.xml.lzma?download"> </repository> <repository uri="https://github.com/git-for-windows/sdk-packages/blob/master/%F.xml.lzma?raw=true"> <package-list catalogue="git-win-sdk-package-list" /> </repository> </profile>
... and then we have to identify all the places that still expect the
msysGitlayout... ;-)Exactly. Your last sentence names the hard part.
Does that mean we have to tweak every mgwport file?
Probably not tweak every file, but we must ensure for every file that it still builds, and if not, then tweak it.
Just to understand the implications. In the curl mgwport file I would need to change
insinto /mingw/include/curlto
insinto /include/curlor?
And while we are at it, it might also make sense to use the generic commands like
doincludeinstead of the ones hardcoding the paths with insinto.Correct.
And how are
$__mpflavor_prefixand friends from mgwport effected?
Or to rephrase my question: Can we write mgwport files which are before and after the switch valid?Can we write mgwport files which are before and after the switch valid?
Probably yes, I don't know and would have to research.
@sschuberth do you think we will have to switch all
#!/bin/shto#!/msys/1.0/bin/shwith this switch? If so, I think we should not switch.No, I'm very sure we don't need to do that, as Shell scripts that come from upstream also don't have that.
Hmm, maybe we need to re-think this. In upstream MinGW / MSYS (installed to
C:\MinGW), if you startC:\MinGW\msys\1.0\msys.bat, you get this:$ cd / $ pwd -W C:/MinGW/msys/1.0I.e., a
cd /does not take you to the installation directory, but to the root of the MSYS directory. While this makes sense from an MSYS point of view, it makes it unnecessary hard to access files inC:\MinGWfrom the MSYS shell. So, what do you think, should we keep things as-is?59 remaining items
- added a commit that references this issue
on Aug 13, 2025 - added 2 commits that reference this issue
on Dec 9, 2025 - added 2 commits that reference this issue
on Dec 11, 2025 - added 2 commits that reference this issue
on Jan 8, 2026 - added a commit that references this issue
on Jan 29, 2026 - added 4 commits that reference this issue
on Jun 25, 2026 - added a commit that references this issue
on Sep 14, 2026
Currently we have "swapped" the MSYS and MinGW directory trees via a profile.xml to match what we had for msysgit. However, it makes more sense for us to simplify things by aligning the directory layout again with upstream MSYS.