주변을 검색했지만이 3 가지 버전의 MSYS로 진행중인 작업에 대한 자세한 설명을 찾을 수 없습니다. MSYS는 MinGW를 사용한 개발을 지원하기위한 최소한의 Linux 도구 포트라는 것을 이해합니다. 그러나 그 둘 사이의 관계에 대해서는 명확하지 않습니다. 개발 / 유지 관리 팀.
해결해야 할 특정 문제 :
- 어느 것이 활발하게 개발되고 있습니까? (특히 MSYS가 종료되었고 MSYS2가 활성화되어 있습니까?)
- 그들을 유지하는 그룹 사이의 관계는 무엇입니까? (특히 MSYS 팀이 MSYS2를 만들었습니까?)
- msysgit은 다른 것 중 하나만 사용합니까, 아니면 자체 MSYS 분기를 가지고 있습니까?
- 서로 호환되는 것이 있습니까?
- 특정 버전의 Windows와의 호환성 문제가 있습니까?
- 하나는 다른 것보다 주요 기능을 제공합니까?
답변
면책 조항 : 저는 MSYS2 개발자입니다
MSYS는 죽지 않았지만 건강에 좋지 않다고 말할 수 있습니다. 몇 년 전 MinGW 팀 이 Cygwin 을 따라 가지 않은 Cygwin의 포크 로 시작한 프로젝트 입니다.
msysgit은 약간의 이전 버전의 MSYS 포크이며 일부 사용자 지정 패치, 이전 버전의 Bash 및 Perl 및 기본 포트 Git이 있습니다.
MSYS2는 Mingw-builds 팀의 Alexey Pavlov (MinGW-w64 툴체인의 공식 패키지 관리자) 가 최근 Cygwin을 밀접하게 추적하는 최신 Cygwin 포크 로 시작한 프로젝트 입니다 . Alexey는 이전 MSYS 패치를 포팅하고 자신의 패치를 추가했습니다.
MSYS의 목표 인 네이티브 소프트웨어를 컴파일하는 데 필요한 유닉스 도구를 제공 할뿐만 아니라 우리 는 Arch Linux 에서 Pacman 패키지 관리자를 이식했습니다 . Pacman은 바이너리 꾸러미를 관리하는 것 이상의 의미를 지닙니다. makepkg라는 소프트웨어 빌드 인프라가있어 소프트웨어 빌드를위한 레시피 (PKGBUILD 및 패치 파일)를 작성할 수 있습니다.
IMHO는 Pacman을 채택하여 Windows의 오픈 소스 개발을 위해 크게 변화했습니다. 모든 사람들이 자신의 맞춤형 쉘 스크립트를 해킹하는 대신 호환되지 않는 방식으로 소프트웨어를 빌드하는 대신 패키지는 이제 다른 패키지에 의존 할 수 있으며 PKGBUILD 파일을 사용하고 관련 패치를 새로운 PKGBUILD 구성을위한 참조로 사용할 수 있습니다. 그것은 (기본) Windows가 얻을 수있는 것 (특히 Linux)과 마찬가지로 Linux 시스템에 가깝고 설치된 모든 패키지를 간단하게 업데이트 할 수 있습니다.
Windows XP SP3을 최소로 대상으로하며 32 비트 및 64 비트 Windows를 모두 지원합니다. MSYS2와 msys 또는 msysgit을 절대 섞지 말 것을 요청합니다. Pacman은 전체 시스템을 관리하는 데 사용되므로 다른 시스템의 파일은 충돌을 일으킬 수 있습니다.
우리는 또한 우리가 구축 한 프로젝트에 패치를 업스트림하고 다른 오픈 소스 프로젝트의 기여를 적극적으로 요청합니다. 우리는 다른 사람들이 우리와 함께 일하기 쉽기를 바랍니다.
우리의 주요 웹 사이트는 SourceForge 에 있으며 PKGBUILD 저장소에 대한 링크가 포함되어 있습니다. 또한 GitHub 에는보다 사용자 친화적 인 설치 관리자 사이트가 있습니다 .
더 자세한 정보가 필요하시면 IRC (oftc # msys2)를 이용해 주시기 바랍니다.
답변
Git 2.8 (2016 년 3 월)에는 2015 년 초 msysgit 을 대체 한 새로운 git-for-windows 의 msys2의 중요성을 설명하는 매우 자세한 커밋이 포함되어 있습니다.
Johannes Schindelin ( )의 commit df5218b (2016 년 1 월 13 일)를 참조하십시오 . ( Junio C Hamano 에 의해 합병 — 커밋 116a866 , 2016 년 1 월 29 일)dscho
gitster
오랜 시간 동안 Windows 용 Git은 Git의 2.x 릴리스보다 뒤떨어졌습니다. Windows 용 Git 개발자는 MSys에서 MSys2 로의 필요한 점프와 함께 큰 도약을 원했기 때문에 Git의 2.x 릴리스보다 뒤떨어졌습니다.
이것이 왜 그렇게 큰 문제인지 이해하려면 Git의 많은 부분이 이식 가능한 C로 작성되지 않았지만 Git은 POSIX 셸과 Perl을 사용하여 사용할 수 있습니다 .
스크립트를 지원하기 위해 Git for Windows는 Bash와 Perl이 포함 된 최소 POSIX 에뮬레이션 레이어를 제공해야하며 2007 년 8 월 Windows Git 노력이 시작되면 Cygwin의 제거 된 버전 인 MSys 를 사용하기로 결정했습니다 .
결과적으로 프로젝트의 원래 이름은 “msysGit”입니다. 슬프게도 Windows 사용자가 MSys에 대해 잘 알지 못하고 관리가 덜 되었기 때문에 많은 혼란을 초래했습니다 .Windows 용 Git의 C 코드를 컴파일하기 위해 MSys도 사용되었습니다. 두 가지 버전의 GNU C 컴파일러를 지원합니다.
- POSIX 에뮬레이션 레이어에 암시 적으로 연결되는 것
- 그리고 평범한 Win32 API를 목표로하는 또 하나의 API가 있습니다 (몇 가지 편리한 함수가 던져졌습니다).
Git for Windows의 실행 파일은 후자를 사용하여 빌드되므로 실제로는 Win32 프로그램입니다. POSIX 에뮬레이션 계층이 필요하지 않은 실행 파일을 식별하지 않는 실행 파일을 식별하기 위해 MSys 실행 파일이라고 할 때 후자를 MinGW (Windows 용 최소 GNU)라고합니다 .
그러나 MSys에 대한 이러한 의존은 다음과 같은 문제를 야기했습니다.
- Windows 용 Git을 더 잘 지원하는 데 필요한 MSys 런타임에 대한 일부 변경 사항은 업스트림에 수용되지 않았으므로 자체 포크를 유지해야했습니다.
- 또한 MSys 런타임은 UTF-8 또는 64 비트를 지원하기 위해 추가로 개발되지 않았으며 훨씬 나중에 (
mingw-get도입 될 때까지) 패키지 관리 시스템이 부족한 것 외에도 MSys / MinGW 프로젝트에서 제공하는 많은 패키지가 각각에 비해 뒤떨어졌습니다. 소스 코드 버전, 특히 Bash 및 OpenSSL.잠시 동안 Git for Windows 프로젝트는 최신 버전의 패키지를 빌드하여 상황을 해결하려고 시도했지만 특히 Git 개발과 관련이없는 신속한 조치가 필요한 Heartbleed 버그와 같은 문제로 상황을 빠르게 해결할 수 없었습니다. 더 Windows.
다행히도 MSys2 프로젝트 ( https://msys2.github.io/ )가 등장하여 Windows 2.x 용 Git의 기반으로 선택되었습니다.
MSys와 마찬가지로 MSys2도 Cygwin의 제거 된 버전이지만 Cygwin의 소스 코드를 통해 최신 상태로 유지됩니다 .
따라서 이미 내부적으로 유니 코드를 지원하며 Windows 용 Git 프로젝트가 시작된 이래로 64 비트 지원을 제공합니다.MSys2는 또한 아치 리눅스에서 팩맨 패키지 관리 시스템을 포팅하여 많이 사용했다 . 이렇게하면 Linux 사용자가
yum또는에서apt-get, MacOSX 사용자가 Homebrew 또는 MacPorts에서 또는 포트 시스템의 BSD 사용자에서 MSys2 로 사용하는 것과 동일한 편의성이 제공 됩니다.pacman -Syu설치된 모든 패키지를 최신 버전 으로 간단 하게 업데이트합니다. 지금 사용 가능.MSys2도 매우 활발하며 일반적으로 일주일에 여러 번 패키지 업데이트를 제공합니다.
Git의 테스트 스위트가 통과 한 상태로 모든 것을 가져 오는 데 2 개월의 노력이 필요했으며, 최초의 공식 Git for Windows 2.x가 출시 될 때까지 몇 달이 더 걸렸으며, 몇 가지 패치가 여전히 각 업스트림 프로젝트에 제출되기를 기다리고 있습니다. . 그러나 MSys2가 없다면 Windows 용 Git의 현대화는 결코 일어나지 않았을 것 입니다.
이 커밋은 MSys2 기반 Git 빌드를 지원하기위한 토대를 마련합니다.
의견 에서 2016 년 1 월에 질문이 제기되었습니다.
Windows 용 Git은 이미 MSYS2를 기반으로하므로 에뮬레이션 계층에 의존하지 않는 바이너리가 MSYS2 패키지로 제공 되었습니까?
Ray Donnelly 는 당시 대답했습니다.
우리는 아직 완전히 합병하지 않았습니다. 우리는 노력하고 있습니다.
하지만 … madz의 종료 지점 초기 2017 동안 즉, 이러한 노력은 못했죠.
보다:
문제는 변경 사항을 적시에 적용하여 새로운 msys2 런타임을 적시에 가져올 수 없다는 것입니다.
그러나 큰 문제는 아닙니다. Windows 용 Git 포크를 무기한으로 계속 실행하겠습니다.
따라서 위키 는 이제 언급합니다 (2018) :
Git for Windows는 업스트림으로 전송되지 않은 msys2-runtime 용 패치를 생성했습니다. (이것은 계획되었지만 문제 # 284에서 발생하지 않았을 것으로 판단되었습니다.)
이것은 MSYS2 내부에서 완전히 작동하는 git을 갖도록 Windows 사용자 정의 msys2-runtime 용 Git을 설치해야 함을 의미합니다.
이후, 그 주 aeb582a9을 커밋 (힘내 2.22, Q2 2019), 윈도우 프로젝트에 대한 힘내 Cygwin에서 v3.x.에 따라 MSYS2 런타임 버전으로 업그레이드 프로세스를 시작
mingw: MSYS2 런타임 v3.x로 빌드 허용최근 Git for Windows 프로젝트는 Cygwin v3.x를 기반으로 MSYS2 런타임 버전으로 업그레이드 프로세스를 시작했습니다.
이는
$(uname -r)더 이상 “2”로 시작하는 버전을보고하지 않고 “3”으로 버전을보고하는 매우 중요한 결과입니다 .df5218b (
config.mak.uname: 지원 MSys2, 2016-01-13, Git v2.8.0-rc0)는 단순히보고 된 버전uname -r이 기본 Cygwin 버전에 의존 할 것으로 예상하지 않았기 때문에 빌드를 중단 합니다.보고 된 버전이 ” “MSYS2″에서 2 “.“1”(MSys)로 시작하는 버전 이외의 다른 것을 테스트하기 위해 테스트 케이스를 뒤집어 봅시다 .
Cygwin이 314.272.65536과 같은 버전을 출시하더라도 미래를 위해 우리를 보호해야합니다.
Git 2.22 (Q2 2019)는 MSYS2 런타임 v3.x 시리즈 업데이트에 대한 미래 테스트를 제공합니다.
Johannes Schindelin ( )의 commit c871fbe (2019 년 5 월 7 일)를 참조하십시오 . ( Junio C Hamano 에 의해 병합 — 커밋 b20b8fe , 2019 년 5 월 19 일)dscho
gitster
t6500(mingw): 쉘의 Windows PID를 사용하십시오.Windows 용 Git에서는 Cygwin의 POSIX 에뮬레이션 계층에서 비표준 PID 모델을 상속하는 MSYS2 Bash를 사용합니다. 모든 MSYS2 프로세스에는 일반 Windows PID가 있으며 MSYS2 PID도 있습니다 (이는 에뮬레이트하는 섀도우 프로세스에 해당) 유닉스 스타일의 신호 처리).
MSYS2 런타임 v3.x로 업그레이드하면이 새도우 프로세스는
OpenProcess()더 이상 액세스 할 수 없으므로 t6500은 참조 된 프로세스gc.pid(실제로 실제gc컨텍스트는 아니지만 현재 쉘) 가 참조하지 않는다고 잘못 생각했습니다. 존재합니다.
gc.pid이 테스트 스크립트에 Windows PID가 작성되어git.exe해당 프로세스가 실제로 존재 함을 이해할 수 있도록하여이를 수정하십시오
.
답변
그들 사이의 연결에 대한 나의 이해는
- Cygwin 은 창 위에 POSIX 에뮬레이션을 제공합니다
- msys 는 Cygwin을 단순화하려고했지만 2010 년부터 폐기되었습니다.
- msysGit- 이전 버전의 msys를 기반으로 Windows에서 최대 1.9.4 ( git-for-windows-1.X 라고 함)를 허용했습니다 .
- msys2- 간결한 Cygwin, msys의 변경 사항으로 Pacman과 통합 된 Cygwin의 기능과 동기화
- MinGW- 초기 MinGW (2010에서 포기 됨)
- MinGW-w64- POSIX를 사용하지 않고 창과 더 빠르고 효과적으로 통합
- git-for-windows-2.x- MinGW-64 , MinGW-32를 사용하여 Windows 용 2.X에서 Git을 제공 하며 msys2 로 대체하여 불가능한 경우
인어에서 완전한 그래프 정의 와 바이올린 .
