Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[R-package] Fallback to MinGW when VS build fails #664

Merged
merged 15 commits into from
Jul 13, 2017
Merged

[R-package] Fallback to MinGW when VS build fails #664

merged 15 commits into from
Jul 13, 2017

Conversation

Laurae2
Copy link
Contributor

@Laurae2 Laurae2 commented Jun 30, 2017

This PR is to help the release of CRAN package of LightGBM.

It removes Visual Studio requirement on Windows. User may still install LightGBM with Visual Studio from GitHub using Laurae2/lgbdl.

MinGW should be the default for the following reasons in Windows:

  • R expects MinGW compilation
  • Rtools, mandatory to start compiling packages, uses MinGW / gcc
  • Rtools is most likely installed than Visual Studio
  • CRAN does not use Visual Studio
  • Precompiled DLLs for CRAN are last resort only

Updates:

  • MinGW instead of Visual Studio by default
  • R README.md documentation to reflect changes

See issue #629.

@guolinke
Copy link
Collaborator

guolinke commented Jul 6, 2017

@Laurae2 Did you test the build with MinGW ?
Does it use the mingw in Rtools, or need to install a standalone MinGW ?

@Laurae2
Copy link
Contributor Author

Laurae2 commented Jul 6, 2017

@guolinke It seems to work now.

It does not need a separate MinGW, by default it should use Rtools.

@Laurae2
Copy link
Contributor Author

Laurae2 commented Jul 6, 2017

@guolinke In Windows, cmake with Rtools requires to run twice because Rtools has sh.exe which cmake does not like (must be run twice to bypass the error). If running twice and using another MinGW without Rtools, it won't cause an error because cmake will tell a warning that it has already configured LightGBM for MinGW.

@guolinke
Copy link
Collaborator

guolinke commented Jul 9, 2017

@Laurae2
I am thinking can we add a parameter named build_cran to https://github.com/Microsoft/LightGBM/blob/master/R-package/build_package.R ?
if build_cran is true, we change the default compiler to mingw in windows.

@Laurae2
Copy link
Contributor Author

Laurae2 commented Jul 13, 2017

@guolinke We already have use_mingw in install.libs.R, we may rename it to build_cran to specify building with minimum requirements (cmake / Rtools).

But in any case, Rtools must be the default choice and VS an optional choice (not the other way around, it makes it unpractical especially for automated installations and future CRAN release).

@guolinke
Copy link
Collaborator

guolinke commented Jul 13, 2017

@Laurae2 Thanks. I think we can list the installed compilers by using cmake --help. And using visual studio if it is installed, otherwise using the rtools.

BTW, does these cran test machine have the cmake ?

cmake_cmd <- paste0(cmake_base, " -DCMAKE_GENERATOR_PLATFORM=x64 ")
tryVS <- system(paste0(cmake_cmd, " .."))
if (tryVS == 1) {
cmake_cmd <- paste0(cmake_base, " -G \"MinGW Makefiles\" ") # Switch to MinGW on failure, try build once
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is better to remove all cmake caches if last camke is fail. you can delete all contents in build folder.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know where is the build folder in all the folders? I can't seem to get rid of it.

Objective would be:

  • try VS build
  • if VS build fails, try MinGW build but delete build folder first (I don't know where is the build folder in all the folders)

if (tryVS == 1) {
cmake_cmd <- paste0(cmake_base, " -G \"MinGW Makefiles\" ") # Switch to MinGW on failure, try build once
system(paste0(cmake_cmd, " ..")) # Must build twice for Windows due sh.exe in Rtools
}
build_cmd <- "cmake --build . --target _lightgbm --config Release"
lib_folder <- file.path(R_PACKAGE_SOURCE, "src/Release", fsep = "/")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lib_path should change if vs build failed

build_cmd <- "mingw32-make.exe _lightgbm -j4"
cmake_cmd <- paste0(cmake_base, " -G \"MinGW Makefiles\" ")
build_cmd <- "mingw32-make.exe _lightgbm -j"
system(paste0(cmake_cmd, " ..")) # Must build twice for Windows due sh.exe in Rtools
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It that okay for double cmake for vs ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double cmake for VS does not cause issues.

This is the message printed when using twice cmake with VS: CMake does not need to re-run because C:/tmp/RtmpygCFH6/devtools19ad439764e21/Laurae2-LightGBM-ed00f7b/R-package/src/build/CMakeFiles/generate.stamp is up-to-date.

@@ -56,6 +56,7 @@ if (!use_precompile) {
cmake_cmd <- paste0(cmake_base, " -DCMAKE_GENERATOR_PLATFORM=x64 ")
tryVS <- system(paste0(cmake_cmd, " .."))
if (tryVS == 1) {
system("rm -rf .")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure the rm -rf can work in windows or not. you can use unlink("./*", recursive = TRUE)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It works with your method.

rm rf works, but I was denied access to remove . or .. apparently.

@Laurae2
Copy link
Contributor Author

Laurae2 commented Jul 13, 2017

@guolinke CRAN test machines should have cmake because there are packages requiring cmake.

For instance, this CRAN package requires cmake: https://cran.r-project.org/web/packages/zstdr/index.html

@Laurae2
Copy link
Contributor Author

Laurae2 commented Jul 13, 2017

@guolinke Build passing on my VS+MinGW Windows machine (VS selection) and MinGW Windows machine (VS failed, auto fallback to MinGW) now.

@Laurae2
Copy link
Contributor Author

Laurae2 commented Jul 13, 2017

but getting this error now on my MinGW-only machine:

Error in eval(ei, envir) : Cannot find lib_lightgbm.dll

@guolinke
Copy link
Collaborator

lib_path should change if vs build failed

@guolinke
Copy link
Collaborator

@Laurae2 Thanks, can you also update the documents ?

@Laurae2
Copy link
Contributor Author

Laurae2 commented Jul 13, 2017

Success on both machines, using R 3.4.0:

VS + MinGW machine:

> devtools::install_github("Laurae2/LightGBM@patch-2", subdir = "R-package")
(...)
** building package indices
** testing if installed package can be loaded
Warning: package 'R6' was built under R version 3.4.1
* DONE (lightgbm)
Warning message:
GitHub repo contains submodules, may not function as expected! 

MinGW-only machine:

> devtools::install_github("Laurae2/LightGBM@patch-2", subdir = "R-package")
(...)
** building package indices
** testing if installed package can be loaded
Warning: package 'R6' was built under R version 3.4.1
* DONE (lightgbm)
Warning message:
GitHub repo contains submodules, may not function as expected! 

@Laurae2
Copy link
Contributor Author

Laurae2 commented Jul 13, 2017

@guolinke I'll update docs now to change the default to VS and auto fallback to MinGW for Windows.

The default compiler is Visual Studio (or [MS Build](https://www.visualstudio.com/downloads/#build-tools-for-visual-studio-2017)) in Windows. You also can use [MinGW64](https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/) (x86_64-posix-seh) to compile by setting `use_mingw` to `TRUE` in `R-package/src/install.libs.R`. For MinGW users who wants to install online, please check the end of this document for installation using a helper package ([Laurae2/lgbdl](https://github.com/Laurae2/lgbdl/)).
The default compiler is Rtools or any [MinGW64](https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/) (x86_64-posix-seh) to compile by setting `use_mingw` to `TRUE` in `R-package/src/install.libs.R`. You also can use Visual Studio (or [MS Build](https://www.visualstudio.com/downloads/#build-tools-for-visual-studio-2017)) in Windows.

For Visual Studio users who wants to install online, please check the end of this document for installation using a helper package ([Laurae2/lgbdl](https://github.com/Laurae2/lgbdl/)).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the description in line 19 and 21 should be updated. What do you think ?

@guolinke guolinke changed the title Change VS to MinGW for CRAN [R] fallback to MinGW if VS build fails Jul 13, 2017
@Laurae2 Laurae2 changed the title [R] fallback to MinGW if VS build fails [R-package] Fallback to MinGW when VS build fails Jul 13, 2017
@guolinke
Copy link
Collaborator

Thanks very much. I think now I can merge it.

@guolinke guolinke merged commit 3421bc6 into microsoft:master Jul 13, 2017
@Laurae2 Laurae2 deleted the patch-2 branch July 14, 2017 08:41
guolinke pushed a commit that referenced this pull request Oct 9, 2017
* Change VS -> MinGW for CRAN

* Documentation to switch to MinGW by default

* Force cmake to run twice

* Try again dual build for Rtools

* Switch to cmake for building twice

* Try with Visual Studio as default, MinGW as fallback

* Try to remove VS appropriately when failing

* Attempt to get rid of build folder first

* Switch to unlink from rm rf

* Change lib_folder correctly when VS fails

* Add README updates from 1c8355c

* Update default compiler doc and add GPU online install doc

* Better GPU doc
@lock lock bot locked as resolved and limited conversation to collaborators Mar 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants