개발/윈도우에서 빌드

From The Document Foundation Wiki
Jump to: navigation, search
This page is a translated version of the page Development/BuildingOnWindows and the translation is 35% complete.

Other languages:
العربية • ‎Deutsch • ‎English • ‎español • ‎italiano • ‎日本語 • ‎한국어 • ‎português do Brasil • ‎русский

빌드 종속성

윈도우에서 리브레오피스를 해킹 시작 하기 전, 다음의 지시에 따라 빌드 환경을 설정해야합니다. 또한 개발/일반적인 빌드 힌트를 보십시오.

비주얼 스튜디오 설치

빌드를 하려면 마이크로소프트사의 컴파일러/개발도구 "Visual Studio"가 필요합니다. 이 도구는 여기서 얻을 수 있습니다. https://visualstudio.microsoft.com/downloads/

모든 LibreOffice 기능을 빌드하는 데 필요한 모든 것을 포함하는 무료버전인 Community Edition이 있습니다. https://visualstudio.microsoft.com/vs/community/

현재 마스터(리브레오피스 7.0부터) "Visual 2019"(적어도 "16.4"버전부터)(또는 Visual Studio Build Tool에 대응하는)가 필요합니다.

VS 2017부터 Visual Studio IDE를 설치하지 않고 컴파일러와 대부분의 툴체인 및 라이브러리를 포함하는 별도의 빌드 도구 패키지를 사용할 수 있습니다. https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2019

이전 LibreOffice 버전의 경우 필요한 Visual Studio 버전은 다음과 같습니다.

  • LibreOffice 4.4는 Visual Studio 2012가 필요합니다
  • LibreOffice 5.0은 Visual Studio 2013이 필요합니다
  • LibreOffice 5.4는 Visual Studio 2015가 필요합니다
  • LibreOffice 6.2는 Visual Studio 2017이 필요합니다
  • LibreOffice 6.3은 Visual Studio 2017 또는 2019로 구축 할 수 있습니다

Visual Studio 2019는 2017 및 2015 컴파일러 (VS 2015/2017 C++ Buildtools)를 선택적으로 설치할 수 있습니다. 유일하게 누락 된 것은 이전 C ++ 재배포 가능 MSM 패키지이므로, 이전 configure.ac 스크립트는 MSI 패키지를 빌드하기 위해 약간의 패치가 필요합니다.

이전 버전의 Visual Studio는 https://visualstudio.microsoft.com/vs/older-downloads/ 에서 이용 가능합니다

비주얼 스튜디오 2019

최소 v16.4 이상의 Visual Studio (및 Visual Studio Build Tools) 2019는 현재 마스터에서 작동합니다. 가장 쉬운 방법은 Visual Studio에서 "C ++로 데스크톱 개발"워크로드를 설치하는 것입니다. 여기에는 빌드에 필요한 다음의 구성 요소가 대부분 포함되어 있습니다.

  • MSVC v142 - VS 2019 C++ x64/x86 build tools (v14.2x)
  • C++ core features
  • Windows 10 SDK (10.0.xxxxx.x)
  • Windows Universal C Runtime
  • C++ ATL for v142 build tools (x86 & x64)
  • .NET Framework 4.x.x SDK
  • C++ 2019 Redistributable MSMs (MSI 설치 프로그램을 빌드하는 데만 필요합니다. "C ++를 이용한 데스크탑 개발"워크로드의 일부가 아닙니다.)
  • C++ Clang Compiler for Windows (9.0.0) ("C++를 이용한 데스크탑 개발"워크로드의 일부가 아닙니다.)

VS 2019 설치 프로그램에서 이러한 옵션을 선택할 수 있습니다.

재배포 가능한 MSM(MSI 설치에만 필요)은 2019년 워크로드 선택의 일부가 아니라 개개의 컴포넌트 선택 중에서 선택해야 합니다. 자세한 내용은 VS 개발자 커뮤니티의 질문Where MergeModules for 14.20.27404.0 and 14.20.27508? 그리고Deprecation of CRT redist MSMs? 에 대한 코멘트를 참조하십시오.

Im-jabber.svg

Note:
Visual Studio command-line tools use system OEM codepage to output messages to console, when corresponding UI language is installed as part of Visual Studio installation. The OEM codepage on Windows depends on system locale defined using "Language for non-Unicode programs" in intl.cpl applet (description of the setting), and is often incompatible with encoding set in cygwin shell (typically UTF-8). This garbles the output from the tools in the build log.
You might want to make sure that you only install English UI when installing Visual Studio to avoid that problem.

자바 설치

어떤 버전의 Visual Studio를 사용하든 관계없이, 필요 합니다

Java Development Kit 9버전 이상. 윈도우 64bit, 32bit에 따라 동일한 bit의 SDK가 필요합니다. 아래의 링크를 통해 구할 수 있습니다. 오라클의 경우 다운로드를 위해서 로그인을 필요로 합니다. https://adoptopenjdk.net/ adoptopenjdk.net http://www.oracle.com/technetwork/java/javase/downloads/index.html oracle.com

Oracle JDK가 64 비트 전용인 것에 주의하십시오.

AdoptOpenJDK 설치 프로그램이 즉시 검색되지 않는 것에 주의하십시오: 이에 대한 "JavaSoft (Orace) 레지스트리 키" 옵션을 수동으로 실행해야 합니다.

시그윈(Cygwin)과 그 외 종속성에 대한 소프트웨어 설치

{{note|The Easiest way to perform the following is to use LODE , which automates all that is necessary, beyond installing Visual Studio and Java.

더 열심히 많은 것을 알고 싶다면, 계속 읽어주세요.

시그윈(Cygwin) 요구사항 설치

Windows 에서는 www.cygwin.com에서 Cygwin을 설치해야 합니다. 권장 버전: 2.11 또는 그 이후버전.

가장 간단한 방법은 Cygwin의 setup-x86.exe (32비트) 또는 setup-x86_64.exe (64비트)를 다운로드하는 것입니다.

  • 가능하면 64비트 Cygwin을 사용하는 것이 좋습니다.포크() 문제가 발생할 가능성이 낮기 때문입니다 (자세한 내용은 Cygwin FAQ를 참조하십시오).

이 지침은 64 비트 버전을 예로 사용합니다. cmd를 실행하고 다운로드 디렉토리로 이동합니다 (탐색에 문제가있는 경우 setup-x86_64.exe를 파일 탐색기에서 cmd 창으로 드래그 할 수도 있습니다) 복사하고 아래 명령을 붙여 넣기하여 사전 선택된 필수 패키지목록과 함께 setup-x86_64.exe를 실행합니다.

  setup-x86_64.exe -P autoconf -P automake -P bison -P cabextract -P doxygen -P flex -P gcc-g++ ^
                -P gettext-devel git -P gnupg -P gperf -P make -P mintty ^
                -P nasm -P openssh -P openssl -P patch -P perl -P python -P python3 ^
                -P pkg-config -P rsync -P unzip -P vim -P wget -P zip -P perl-Archive-Zip ^
                -P perl-Font-TTF -P perl-IO-String

이렇게하면 GUI가 시작되고 설치 경로 등을 수동으로 선택해야하지만 명령 줄을 통해 전달 된 패키지는 미리 선택되어 있으므로 선택을 수락하면됩니다.

참고: Cygwin의 설치 경로에 ASCII가 아닌 문자가 포함되어 있지 않아야 autogen.sh/configure 문제를 피할 수 있습니다.(포함된 경우, Cygwin 설치 폴더를 새 위치로 이동하고 Windows 바로 가기 & 시작 메뉴 항목을 업데이트하십시오).

대안으로는, setup-x86.exe 또는 setup-x86_64.exe 유틸리티를 실행한 후,'전체'가 옆에 표시될 때까지 '보기'를 눌러 패키지 보기 모드를 '전체'로 전환하십시오, 다음 설치를 위해 위의 명령에 나열된 패키지를 수동으로 선택하십시오.

Cygwin을 업그레이드한 경우' rebaseall 명령을 실행해야 할 수 있습니다.(Cygwin을 처음 설치한 경우에는 필요 없음):

모든 Cygwin 콘솔을 닫고, <c:\c:\cygwin\bin\dash.exe>를 실행하고 터미널에서 /bin/rebaseall를 실행하십시오.

그외 종속성들

Cygwin을 설치 한 후 바탕 화면 아이콘 Cygwin64 Terminal을 클릭하여 Cygwin 명령 줄을 열고 다음 단계를 수행하십시오.

GNU make 설치

Win32의 GNU 빌드 4.0+는 Libre Office 구축에 이용 가능합니다.(필요합니다.)

It's easiest to put it in /opt/lo/bin, where configure will automatically find it; you can also use another location and set the MAKE variable. Either prepend /opt/lo/bin to PATH, or alternatively, when you build LibreOffice, always call "make" with the absolute path /opt/lo/bin/make (or wherever you put it). LibreOffice can not and should not use Cygwin's /usr/bin/make.

mkdir -p /opt/lo/bin
cd /opt/lo/bin
wget https://dev-www.libreoffice.org/bin/cygwin/make-4.2.1-msvc.exe
cp make-4.2.1-msvc.exe make
chmod +x make
ant와 junit 설치

어디서든 추출할 수 있어, 설치하지 않아도 됩니다. 주니트를 사용하기 싫으면, 자동생성기로 --without-junit를 사용하여 무효화 할 수 있습니다. sh 명령어를 사용한 후에.

  mkdir -p /cygdrive/c/sources
  cd /cygdrive/c/sources
  wget https://archive.apache.org/dist/ant/binaries/apache-ant-1.9.5-bin.tar.bz2
  tar -xjvf apache-ant-1.9.5-bin.tar.bz2
  wget http://downloads.sourceforge.net/project/junit/junit/4.10/junit-4.10.jar

Also works with the combination of junit 4.13,hamcrest 2.2 and Apache Ant 1.10.8

리브레오피스 소스코드 저장소를 복사하세요.

참고: 소스들은 파일/경로 이름 제한 및 대상 경로를 초과하지 않도록 비교적 짧은 경로로 해야 하며 타겟 경로에 공간을 포함할 수 없습니다.

  cd /cygdrive/c/sources
  git clone https://gerrit.libreoffice.org/core libo-core
선택적으로 빌드 디렉토리 생성

당신은 LibreOffice를 당신의 체크아웃이 아닌 다른 디렉토리에 "만들 수 있습니다". 이것은 소스 코드 트리를 청결하게 유지하고 여러 버전을 쉽게 만들 수 있는데 도움이 됩니다.

별도의 경로에 빌드하고 싶다면, 예를들어 /cygdrive/c/build, 다음의 명령어들을 입력하세요:

  mkdir /cygdrive/c/build
  cd /cygdrive/c/build

"기타" 해당 경로를 /cygdrive/c/sources/libo-core 폴더로 변경 :

  cd /cygdrive/c/sources/libo-core
설정 및 코드 빌드

빌드 설정을 위해 autogen.sh를 실행하세요.

  /cygdrive/c/sources/libo-core/autogen.sh \
               --with-external-tar=/cygdrive/c/sources/lo-externalsrc \
               --with-junit=/cygdrive/c/sources/junit-4.10.jar \
               --with-ant-home=/cygdrive/c/sources/apache-ant-1.9.5 \
               --enable-pch --disable-ccache \
               [additional switches, if you know what you are doing :-) ...]

Note that it's not recommended to use ccache on Windows. If you have it installed in your Cygwin environment, be safe and disable it with --disable-ccache (as in the command above).

If the autogen.sh script complains that it cannot find some header files, it is possible that it cannot locate the your Windows SDK or that it finds a corrupted one. This may happen if you installed multiple version of Visual Studio on your computer, especially if you installed a Beta version, and even if you uninstalled those. In this case, you may use the --with-windows-sdk=7.1A, possibly replacing 7.1A with another version of the SDK to select a specific uncorrupted version.

Save a copy of the last used parameters in the file autogen.input. It will not be overridden by autogen.sh when using other parameters. If autogen.sh is called again without parameters, it will fetch its input from autogen.input if it is present.

Don't forget to specify --with-jdk-home when you use AdoptOpenJDK in zip format, because configure.ac detects JDK's paths from registry JDK's installer downloadable from Oracle sets. Other JDKs may need this option too(not tested).

Read the summary output from the autogen.sh command. If it did not report any errors or relevant warnings, then all that is left to do is to run the right version of make to build LibreOffice. Before you do this, make sure your anti-virus software will not cause any problems.

   /opt/lo/bin/make gb_COLOR=1  # gb_COLOR=1은 색상출력 가능

If the build process fails at this point with the error error C3861: 'InetPtonW': identifier not found, this is because of a bug in the build process for Windows SDK 8. You may work around this by using the --with-windows-sdk=7.1A option.

LibreOffice 실행하기

빌드가 에러 없이 끝났을 때, LibreOffice의 새로 만든 빌드를 실행할 수 있습니다.

   instdir/program/soffice.exe

Microsoft Visual Studio 프로젝트 통합

LibreOffice 빌드 시스템은 Microsoft Visual Stdio를 포함해 몇몇 IDE에서 프로젝트 파일을 생성할 수 있습니다. -- Honza Havlíček의 멋진 작업에 대해 감사를 -- (전체 빌드를 허용하지 않으므로 전체 빌드를 위해서 여전히 Cygwin을 사용해야한다는 것을 주의하세요.)

Visual Studio를 위해 프로젝트 파일 빌드하기

The IDE integration script is written in python3, which is not installed by default (using the lode method), please install it in cygwin before running the make command. After a complete build of LibreOffice was successful, execute the following command to generate a Visual Studio project for Visual Studio 2019:

  $ /opt/lo/bin/make vs2019-ide-integration

For Visual Studio 2017 use:

  $ /opt/lo/bin/make vs2017-ide-integration

If the generation is successful, the resulting solution file LibreOffice.sln will be placed in the root directory of the build and can be opened with Microsoft Visual Studio.

Note that if you use --enable-mergelibs, the generated solution will for unclear reason contain less projects, and have problems finding many symbols. Until that is fixed, it's advisable to avoid --enable-mergelibs when using IDE integration.

왜 MSVC인가?

It is a frequently asked question, usually coming from free software purists, why we use proprietary compiler instead of a free one (i.e. gcc).

  • ABI backwards-compatibility for compiled extensions. There is some resistance to breaking that.
  • So far MSVC produces faster, smaller binaries.
  • There are some features in the code that don't compile with MinGW. They use API that MinGW does not provide headers for etc.
  • There are open questions around how we would run unit tests in a MinGW cross-compilation environment.
  • There are open questions around how well gdb works on Windows; the MSVC C++ debugger is really quite good.

Autogen options

Something like the following in the autogen.input file is known to produce a working build:

--disable-odk
--with-junit=/cygdrive/c/sources/junit-4.10.jar
--with-ant-home=/cygdrive/c/sources/apache-ant-1.9.5

Of course, change the information behind ='s to fit your needs; set the paths to what you have used when installing various prerequisites.

You also need to specify the path for ant with --with-ant-home=<cygwin path of ant>.

64-비트 비주얼 스튜디오 빌드

A port for 64-bit Windows is working on master with all supported compilers. To build it, use the --enable-64-bit flag to configure.

Notes on older and non-default MS compilers

Switching to non-default compiler

Specify which Visual Studio version to use in case several are installed.

If not specified, the order of preference is 2015, 2017 for libreoffice-6-1 (and older branches), 2019 is used for master.

--with-visual-studio=2019

Running Glade on Windows

To edit dialogs (.ui files), you need Glade. There is an old version for Windows but it doesn't support all properties that are needed for LibreOffice dialogs.

So you need to install Glade in Cygwin:

  • Install Glade in Cygwin by running the Cygwin Setup, then install the following packages:
X11, X11 fonts, Gtk3, Glade, OpenGL
  • Add this to your .bashrc:
export GLADE_CATALOG_SEARCH_PATH=<path_to_core>/instdir/share/glade
  • Open one Cygwin console and run:
X -multiwindow
  • Open another Cygwin console and run:
DISPLAY=:0.0 glade.exe

That's it, you should now run Glade ≥ 3.18

Known Problems

Cygwin and git

The main problem is the cygwin-git is very slow.

The alternatives are:

Here are the times using the same computer and repo and not being the first call:

git status

git Version Time [sec]
cygwin 2.21.0 20
win 2.22.0 1
WSL 2.16.0 6

Git in WSL is slower than git-bash, but it has the advantage of working in a complete Linux environment with all other tools provided by the distribution. You should not mix tools from Cygwin and WSL (i.e. open separate terminals for Cygwin and for WSL).

NOTE: A mix between different git tools is not always compatible, when you change you should renew (clone) the git repositories.

Best to configure "autocrlf" before cloning master, to avoid the problem (see below for how to set "autocrlf" to a sensible value)

Cygwin Shell

You will use Cygwin Bash Shell for the whole build process. You must install all the build dependencies above before starting the shell to run autogen because autogen needs some environment variables to find the tools.

If you see an error similar to the following when running autogen.sh

   $'\r': command not found

This means that that windows style newline characters are creating issues with the Cygwin Shell. The good way to solve this is to configure git to clone with UNIX line ending. To do so, in git bash:

   git config --global core.autocrlf input


Big List Of Dodgy Apps

If you get mysterious build breaks, building is very slow or your systems hangs totally, check if you are running an application which interferes with Cygwin. For a list of known offenders, see this point in the Cygwin FAQ.

Buildability of 'master'

If you are building the Windows build for the first time, it is recommended that you check the current state of https://tinderbox.libreoffice.org/MASTER/status.html . If you see recent "green" builds, it is a good time to try - otherwise it might happen to you that you'll have to fix the build yourself. The buildability on Windows has improved recently with the introduction of the MinGW and more stable native Windows tinderboxes, but still there might be a day or two when 'master' is not buildable on Windows.

The usual recommendation is to just pull and try again, and once you have a build, don't pull in the tree any more, but do your hacking in it. Clone a different tree and iterate pulling and building in that until it again works, then switch. Repeat.

Alternatively, if you find a known good state (a green box) for Windows on the Tinderbox side back in history, you can do:

git checkout -b my_workbranchname ${last_good_commit}

to start working on a branch starting at the last good state.

BitDefender / other Anti-Virus / security tools breaking the build

If your build fails with a FileNotFoundError: such as The system cannot find the file specified: '../../../dist/out/bin\\example.exe', there's a good chance your Anti-Virus is quarantining or deleting important files.

Another potential source of problems are the sample documents (those labeled CVE) that check for known vulnerabilities to ensure they don't reappear again. In the source they are stored encrypted to avoid triggering the warnings, but when the corresponding test is run, the original is created in the temp directory and tools such as BitDefender can flag it.

If you want to run these tests, disable monitoring of the temporary build-directories <root of repo>\*\pass and C:\cygwin\tmp in your Anti-Virus tool. For Windows 8 and 10 you will need to disable Windows Defender launch - search for and launch 'defender' from the shell.

You can also use the --disable-cve-tests autogen flag to skip the tests that are known to cause trouble.

Also note that Anti-Virus tools can slow down your build quite a bit, if you want to build fast you should disable real time monitoring of the source tree and the temporary files directory C:\cygwin\tmp.

Norton Antivirus breaking the build

Norton Antivirus and Symantec Endpoint Protection complain about certain files that the build produces. It finds the following files (in a build without "--enable-dbgutil" )

Malware: Suspicious.Cloud
D:\bld\rel\workdir\UnpackedTarball\icu\source\bin\genrb.exe*
Malware: Suspicious.Cloud.5
D:\bld\rel\workdir\UnpackedTarball\nss\nss\lib\zlib\out\example.exe*
D:\bld\rel\workdir\UnpackedTarball\nss\dist\out\bin\example.exe* 
D:\bld\rel\instdir\program\reg4allmsdoc.dll
D:\bld\rel\instdir\program\sdqsmsi.dll
D:\bld\rel\instdir\program\sellangmsi.dll

Files with * are needed for the build - exclude them from the virus scan!

The following files appear with varying names (????) in a release build, so you cannot exclude them from the scan.

D:\bld\rel\instdir\program\RCX????.tmp
D:\bld\rel\instdir\program\RCX????.tmp
D:\bld\rel\instdir\program\RCX????.tmp

Current workaround: Don't do release builds (unless you are allowed/willing to switch off the virus scanner).

System PATH causing weird build breakage

If you experience weird build breakage that no one else seems to experience, check your PATH value and try cleaning it. Note that you need to open a new shell and re-run autogen.sh in order for the new system PATH value to take effect in your build. Some people have experienced a build failure in the shell module due to their system PATH including a path to an older OOo installation which had a DLL of the same name as the one that the build uses.

Windows Update automatically reboot during compilation

Sometimes Microsoft Windows reboot during compilation. It happen because Windows Update updates operating system and reboot. To stop windows update from command line, you can enter following command in command box:

C:> net stop wuauserv

It stops a Windows Update service process.

Failing PDF signing tests

On Windows, it can happen, that PDF signing tests are failing:

[build CUT] xmlsecurity_pdfsigning
warn:sfx.appl:2956:6324:sfx2/source/appl/app.cxx:193: No DDE-Service possible. Error: 16399
warn:svl.crypto:2956:6324:svl/source/crypto/cryptosign.cxx:1415: CryptAcquireCertificatePrivateKey failed: Das Zertifikat und der private Schlüssel für die Entschlüsselung wurden nicht gefunden.
warn:vcl.filter:2956:6324:vcl/source/filter/ipdf/pdfdocument.cxx:846: PDFDocument::Sign: PDFWriter::Sign() failed
C:/Users/davido/projects/libo/xmlsecurity/qa/unit/pdfsigning/pdfsigning.cxx:174:PDFSigningTest::testPDFAdd assertion failed
- Expression: aDocument.Sign(aCertificates[0], "test", true)

Solution: Remove expired Own Certificate: http://imgur.com/a/NdCxT

  1. Start certmgr
  2. proceed to Own Certificates
  3. Remove expired certificate
  4. Repeat the tests
  5. Done

Short filenames (8.3 filenames)

If you get an error like the following one:

configure: error: converted path "C:/PROG~1/Microsoft SDKs/Windows/v8.1A/bin/NETFX4~1.1TO/" still contains spaces. Short filenames (8.3 filenames) support was disabled on this system?
Error running configure at ./autogen.sh line 300.

Then ensure 8.3 name creation is enabled. Open the Command Prompt as administrator and run:

fsutil 8dot3name query c:

Also, check that the conflicting folder (in this case, "Microsoft SDKs") has a corresponding 8.3 filename. For example:

cd C:\Program Files (x86)\
dir /x M*

This will print a list of folders beginning with "M" and their associated 8.3 filenames. If "Microsoft SDKs" does not have a short filename, you can rename it to "tmp", then create a new folder "Microsoft SDKs", check that it has a short filename and move the contents of "tmp" to "Microsoft SDKs".

When choosing a directory in which to install LODE, please use the 8.3 rules. Windows does not correct environment variables, therefore e.g. LODE_HOME will be wrong and will cause problems. Therefore, always clone lode in a 8.3 path such as:

C:\source\LO\lode

autogen.sh might report that it cannot find mscvc.exe.

This is caused by the long filename problem as well, but the solution is a bit more work:

Shift+reset, go to the safe mode, do this:

fsutil 8dot3name set c: 0
fsutil file setshortname "Program Files (x86)" PROGS
fsutil file setshortname "Microsoft Visual Studio 12.0" msvc-12
fsutil file setshortname "Windows Kits" W~Kits

Correct your PATH variable

Windows permission issues

다음과 같은 에러가 생긴다면 :

ALINK : error AL1078: Error signing assembly -- Access is denied.

Then right click and select "properties" of the folder "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" and under the "security" tab modify the permissions of the user and allow "Full control".

See this for more information https://odetocode.com/blogs/scott/archive/2020/01/12/solving-access-denied-in-crypto-machine-keys.aspx

Other known problems

  • Paths that include /opt cause problems with some external modules; it is best to avoid having your source tree in /opt; or use --disable-orcus to overcome this.
  • Asian locale builds sometimes fail due to encoding issues in the source code; in these cases, patches to fix those problems are appreciated. Alternatively, configure Windows for a US locale.

Using a Windows program as your git editor

Paths under Cygwin are an endless source of nightmares. This section documents using Notepad++ as your git editor under Cygwin. It assumes you are using the 64-bit version of Notepad++ (adjust the path, if using the 32-bit version).

Below you will find a wrapper script written by Gene Pavlovsky (original gist in GitHub).

  1. Save the script as cygrun.sh into the bin directory in Cygwin's root (so it is in the PATH). When saving the cygrun.sh using Notepad++, do this first to make sure it has Unix line endings: from the "Edit" menu, select "EOL Conversion" -> "UNIX (LF)".
  2. In a Cygwin shell inside the bin directory, give this command to create a symbolic link:
    ln -s cygrun.sh cygrun
    
  3. Give this command in your home directory:
    git config --global core.editor "cygrun -w 'C:/Program Files/Notepad++/notepad++.exe' --wait"
    
    or alternatively edit your .gitconfig to contain this editor block:
    editor = cygrun -w 'C:/Program Files/Notepad++/notepad++.exe' --wait
    
    The --wait is important, as it forces git to wait until you close the file.

Bonus: if you want to define Notepad++ as the default editor of your shell and also access it through a handy "np" alias, add these to the .bashrc file in your home directory:

export EDITOR="'/cygdrive/c/Program Files/Notepad++/notepad++.exe'"
alias np="'/cygdrive/c/Program Files/Notepad++/notepad++.exe'"

Remember to be very careful with the line endings, when creating new files and use the Edit -> EOL Conversion.

The cygrun script:

#!/bin/bash
#
# Run a program, converting UNIX and Windows format path arguments.
#
# Install in Cygwin's `bin` dir or elsewhere in your path. 
# Create a symlink for convenience: `ln -s cygrun.sh cygrun`.
#
# Use `cygrun -w windows-program unix-path ...` to run Windows programs (e.g. from UNIX software).
# E.g., in my .gitconfig core.editor is set to `cygrun -w 'C:/Program Files/Notepad2/Notepad2.exe'`.
#
# Use `cygrun [-u] unix-program windows-path ...` to run Cygwin programs (e.g. from Windows software).
# Usually not needed since Cygwin translates Windows paths automatically (e.g. `ls 'C:\Windows'` works).
# Still it can be useful in case a Windows program might produce paths that mix backslashes and forward slashes,
# e.g. in Apache Ant `${dist.dir}/file` evaluates to `C:\path\to\project\dist/file`, which Cygwin won't
# translate automatically. So, to deploy the file, I use `cygrun -u scp ${dist.dir}/file ${deploy.url}`.
#
# Use the `-b` option to detach from tty, run the process in background, and return immediately.
#
# There is currently a limitation on passing non-path arguments to a program. Since there is no way
# to automatically distinguish path arguments from non-path arguments, all of the arguments are passed
# to `cygpath`. As long as non-path arguments don't contain `/` or `\` characters, and `-a` or `-C`
# options are not used, `cygpath` will return the arguments unmodified - no problem.
# Due to this, the `-a` and `-C` options are disabled at the moment.
# TODO: Add an option allowing to specify index positions of path arguments (comma-separated, support ranges).
#
# Most of the options are passed as is to `cygpath`, which is used for path conversion.

set -e -o pipefail

usage() {
  local code=${1:-2}
  test $code -ne 0 && exec >&2
  
  echo "Usage: $(basename "$0" .sh) [options] program [argument]..."
  echo
  echo 'Run a program, converting UNIX and Windows format path arguments.'
  echo
  echo 'Output type options:'
  echo
  echo '  -d, --dos             print DOS (short) form of NAMEs (C:\PROGRA~1\)'
  echo '  -m, --mixed           like --windows, but with regular slashes (C:/WINNT)'
  echo '  -u, --unix            (default) print Unix form of NAMEs (/cygdrive/c/winnt)'
  echo '  -w, --windows         print Windows form of NAMEs (C:\WINNT)'
  echo
  echo 'Path conversion options:' 
  echo
  echo '  -U, --proc-cygdrive   Emit /proc/cygdrive path instead of cygdrive prefix'
  echo '                        when converting Windows path to UNIX path.'
  echo '  -c, --codepage CP     print DOS, Windows, or mixed pathname in Windows'
  echo '                        codepage CP.  CP can be a numeric codepage identifier,'
  echo '                        or one of the reserved words ANSI, OEM, or UTF8.'
  echo '                        If this option is missing, cygrun defaults to the'
  echo '                        character set defined by the current locale.'
  echo
  echo "Other 'cygpath' options:"
  echo
  echo '  -f, --file FILE       read FILE for input; use - to read from STDIN'
  echo "  -o, --option          read 'cygpath' options from FILE as well (for use with --file)"
  echo '  -h, --help            output usage information and exit'
  echo
  echo 'Run options:'
  echo
  echo '  -b, --background      run in a new session'
  echo '  -n, --dry-run         print the command that would be executed, and exit'
  
  exit $code
}

run() {
  local -n _run_args=$2
  if test "$dry_run"; then
    test "$chdir" && printf 'cd %s\n' "$chdir"
    printf '%s\n' "$1 ${_run_args[*]}"
  else
    test "$chdir" && cd -- "$chdir"
    if test "$background"; then
      setsid "$1" "${_run_args[@]}" </dev/null &>/dev/null &
    else
      exec "$1" "${_run_args[@]}"
    fi
  fi
}

declare opts fileopts chdir background dry_run
while test $# -gt 0; do
  case $1 in
    -d|--dos|-u|--unix|-m|--mixed|-w|--windows|-U|--proc-cygdrive|-o|--option)
      opts="${opts} $1"
    ;;
    -C|--codepage|-f|--file)
      opts="${opts} $1 $2"
      shift
    ;;
    -f|--file)
      fileopts=1
      opts="${opts} -i $1 $2"
      shift
    ;;
    -b|--background)
      background=1
    ;;
    -n|--dry-run)
      dry_run=1
    ;;
    -h|--help)
      usage 0
    ;;
    --)
      shift
      break
    ;;
    -*)
      script="$(basename "$0" .sh)"
      echo "$script: Unknown option: $1" >&2
      echo "Try '$script --help' for more information." >&2
      exit 2
    ;;
    *)
      break
    ;;
  esac
  shift
done
test "$chdir" && opts="$opts -a"

program=$1
test "$program" || usage
shift

declare -a args
test $# -gt 0 -o "$fileopts" && mapfile -t args < <(cygpath $opts -- "$@" || exit 1)
run "$program" args

더 보기