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

Automatic Inference of MinGW SDK Directory #977

Closed
RoyiAvital opened this issue Oct 3, 2020 · 58 comments
Closed

Automatic Inference of MinGW SDK Directory #977

RoyiAvital opened this issue Oct 3, 2020 · 58 comments

Comments

@RoyiAvital
Copy link

The code in:

function _find_mingwdir(sdkdir)
-- get mingw directory
if not sdkdir then
if is_host("macosx", "linux") and os.isdir("/opt/llvm-mingw") then
sdkdir = "/opt/llvm-mingw"
else
if is_host("macosx") then
sdkdir = "/usr/local/opt/mingw-w64"
elseif is_host("linux") then
sdkdir = "/usr"
end
end
end

Supports only macOS and Linux.
On top of this, it doesn't check for existence, it only sets directories (Which might not exist).

I suggest the following assuming MinGW platform was defined (-p mingw):

  1. If on Windows, Look for Environment Variables GCC_BIN_PATH or GCC_LIB_PATH.
  2. In case they exist define minGwSdk = GCC_BIN_PATH/.. or minGwSdk = GCC_LIB_PATH/.. with priority for the BIN folder.
  3. If not on Windows, do as the code above deines.
  4. Check for existence of minGwSdk. If it doesn't exist return an error.

Step (4) is in case the existence isn't in a later step in the program.

@waruqi
Copy link
Member

waruqi commented Oct 3, 2020

Ok, I will consider improving find_mingw()

In case they exist define minGwSdk = GCC_BIN_PATH/.. or minGwSdk = GCC_LIB_PATH/.. with priority for the BIN folder.

Can you let me see your the content of $GCC_BIN_PATH and $GCC_LIB_PATH?

mingwsdk should be the root directory of the bin/lib directory. e.g.

mingwsdk
  - bin
  - lib
  - include

@RoyiAvital
Copy link
Author

RoyiAvital commented Oct 3, 2020

GCC_BIN_PATH is exactly mingwsdk\bin in your example. Hence mingwsdk = GCC_BIN_PATH\..\.

For instance, its content is:

image

@waruqi
Copy link
Member

waruqi commented Oct 3, 2020

Ok, thanks. BTW, GCC_BIN_PATH these environment variables, are you custom variables, or mingw sdk-specific variables, there are still some standard specifications? Are there any related reference documents?

@RoyiAvital
Copy link
Author

It might depend on the MinGW distribution.
So maybe a better and more robust method is to scan the %PATH% variable for MINGW*/bin and infer from there?

@waruqi
Copy link
Member

waruqi commented Oct 3, 2020

It might depend on the MinGW distribution.
In other words, are these variables GCC_BIN_PATH set by mingw's specific distribution?

and which mingw distribution did you install? I will look at it.

If it is msys2/mingw, maybe we can infer it from /mingw64 and /mingw32.

So maybe a better and more robust method is to scan the %PATH% variable for MINGW*/bin and infer from there?

If a registry key is set, we can detect it from the registry, of course, find it directly from %PATH%, which is also a way to consider.

@RoyiAvital
Copy link
Author

No, I mean to scan the string of %PATH% (The system environment variable for the system path).
Look for a string match of mingw*/bin or mingw*\bin where it needs to be case insensitive (I can probably create the RegEx for that).

Once you find it, only remove the bin and what's after it and you have the SDK path.

No need for registry keys.

@waruqi
Copy link
Member

waruqi commented Oct 3, 2020

BTW, we can run xmake g --mingw=/xxx to set mingwsdk to global configration. then we only need run xmake f -p mingw; xmake to build project each time.

@waruqi
Copy link
Member

waruqi commented Oct 3, 2020

No, I mean to scan the string of %PATH% (The system environment variable for the system path).
Look for a string match of mingw*/bin or mingw*\bin where it needs to be case insensitive (I can probably create the RegEx for that).

Once you find it, only remove the bin and what's after it and you have the SDK path.

No need for registry keys.

I know what you mean, but I mean, if there are registry keys available, I prefer to use the registry first, because it is more reliable than searching from the %PATH% string. Of course, if not, we can continue to try to find it from the %PATH% string.

@RoyiAvital
Copy link
Author

Since MinGW distributions are built to be portable (Namely user can change the folder after installation as long as he change the %PATH%) they don't use registry key.

The only thing I saw all of them expect, is the user to add MinGW_HOME_FOLDER to the path.
Where MinGW_HOME_FOLDER is the place it was installed.

It is better not to use registry. Keep your xmake portable and accessible by using system path and not registry.

@waruqi
Copy link
Member

waruqi commented Oct 3, 2020

But users may also change the directory name of mingwsdk, for example: /xxx/yyy, we may not be able to find it reliably from the %PATH% string. Of course, if there is a general MinGW_HOME_FOLDER, it is of course the best. If every user will go to set it.

@RoyiAvital
Copy link
Author

Advanced use can always do things manually, and then use -p mingw --mingw=<path>.
We're talking on the nominal case. The bin folder will be in path.
In case --mingw= wasn't defined, use the bin folder. Once you extract it, look for gcc.exe in it. If it is there, infer from it the SDK.

I think this is pretty robust and user friendly. It means in most nominal cases using -p mingw will be enough to make all things play well.

@RoyiAvital
Copy link
Author

RoyiAvital commented Oct 3, 2020

By the way, I think a RegEx to capture the mingwsdk from %PATH% should be something like: [;]?([A-Za-z-\\:]*(?i)mingw[A-Za-z\\:-]*)[\\\/]bin.

Test Cases:

  1. Test Case 001 - Middle.
  2. Test Case 002 - Beginning.
  3. Test Case 003 - End.

Update

Better and more robust will be [;]?([\s\w\\\/:-]*(?i)min[\s\W_]*gw[\s\w\\\/:-]*)[\\\/]bin without the Global Flag. See updated Test Case 001 - Middle.

@waruqi
Copy link
Member

waruqi commented Oct 5, 2020

I have improved it, you can update to the dev version and try it again. 5fb2bcc

xmake update dev

@waruqi
Copy link
Member

waruqi commented Oct 5, 2020

Please download installer.exe to install dev version on github ci (https://github.com/xmake-io/xmake/actions/runs/288765711)

xmake update dev will download installer appveyor ci, but the installation package is not ready yet. (https://ci.appveyor.com/project/waruqi/xmake/builds/35566064)

You can also run xmake update -s dev to only update lua scripts.

@waruqi
Copy link
Member

waruqi commented Oct 7, 2020

Does it work?

@RoyiAvital
Copy link
Author

The update fails on my machine (I don't have system wide GIT).
Is there a manual way to do so?

@waruqi
Copy link
Member

waruqi commented Oct 7, 2020

you can download install package from action ci.

https://github.com/xmake-io/xmake/actions/runs/292753296

@RoyiAvital
Copy link
Author

It doesn't work:

xmake f -p mingw -Dv
checking for architecture ... x86_64
checking for mingw directory ... no
please run:
    - xmake config --mingw=xxx
or  - xmake global --mingw=xxx
error: @programdir\core\main.lua:284: @programdir\core\tool\toolchain.lua:194: stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:803]: in function 'raise'
    [@programdir\toolchains\mingw\check.lua:37]:
    [C]: in function 'load'
    [@programdir\core\tool\toolchain.lua:190]: in function 'check'
    [@programdir\core\platform\platform.lua:287]: in function 'check'
    [...mdir\core\sandbox\modules\import\core\project\config.lua:120]: in function 'check'
    [@programdir\actions\config\main.lua:249]:
    [C]: in function 'load'
    [@programdir\core\base\task.lua:520]: in function 'run'
    [@programdir\core\main.lua:282]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:

stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:792: in function 'raise'
        @programdir\core\main.lua:284: in function 'cotask'
        @programdir\core\base\scheduler.lua:317: in function <@programdir\core\base\scheduler.lua:315>

My RegEx can extract the Path to MinGW from my %PATH% so I am not sure why it doesn't work.

This is the version I got from your link:

xmake --version
xmake v2.3.7+202010070503, A cross-platform build utility based on Lua
Copyright (C) 2015-2020 Ruki Wang, tboox.org, xmake.io

@waruqi
Copy link
Member

waruqi commented Oct 7, 2020

can you add -c to xmake f to ignore last cached result and try it again.

xmake f -p mingw -Dv -c

@RoyiAvital
Copy link
Author

I manually deleted .xmake.
But anyhow:

xmake f -p mingw -Dv -c
checking for architecture ... x86_64
checking for mingw directory ... no
please run:
    - xmake config --mingw=xxx
or  - xmake global --mingw=xxx
error: @programdir\core\main.lua:284: @programdir\core\tool\toolchain.lua:194: stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:803]: in function 'raise'
    [@programdir\toolchains\mingw\check.lua:37]:
    [C]: in function 'load'
    [@programdir\core\tool\toolchain.lua:190]: in function 'check'
    [@programdir\core\platform\platform.lua:287]: in function 'check'
    [...mdir\core\sandbox\modules\import\core\project\config.lua:120]: in function 'check'
    [@programdir\actions\config\main.lua:249]:
    [C]: in function 'load'
    [@programdir\core\base\task.lua:520]: in function 'run'
    [@programdir\core\main.lua:282]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:

stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:792: in function 'raise'
        @programdir\core\main.lua:284: in function 'cotask'
        @programdir\core\base\scheduler.lua:317: in function <@programdir\core\base\scheduler.lua:315>

Same result.

@waruqi
Copy link
Member

waruqi commented Oct 7, 2020

Can you let me see your %PATH%? I will look at it.

@RoyiAvital
Copy link
Author

Here is a link to it: https://pastebin.ubuntu.com/p/WFwKtxwDpM/

@waruqi
Copy link
Member

waruqi commented Oct 7, 2020

ok, I have improved it. You can wait some time, then re-download install package from https://github.com/xmake-io/xmake/actions/runs/292952854

@RoyiAvital
Copy link
Author

What was the issue? Why not use my RegEx? It should be robust to all cases.

@waruqi
Copy link
Member

waruqi commented Oct 7, 2020

I have fixed the case sensitivity problem. Lua does not support regular expressions, only Lua pattern matching. But it's enough.

Dose it work now?

@RoyiAvital
Copy link
Author

While the inference worked:

xmake f -p mingw -Dv -c
checking for architecture ... x86_64
checking for mingw directory ... D:\Applications\Programming\MinGW
configure
{
    host = windows
    buildir = build
    kind = static
    cross =
    mingw = D:\Applications\Programming\MinGW
    ccache = true
    mode = release
    bin = D:\Applications\Programming\MinGW\bin
    plat = mingw
    clean = true
    ndk_stdcxx = true
    arch = x86_64
}

The compilation itself didn't:

xmake -v -w
checking for x86_64-w64-mingw32-gcc ... no
checking for the c++ compiler (cxx: x86_64-w64-mingw32-gcc) ... no
checking for x86_64-w64-mingw32-g++ ... no
checking for the c++ compiler (cxx: x86_64-w64-mingw32-g++) ... no
checking for the c++ compiler (cxx: x86_64-w64-mingw32-gcc) ... no
checking for the c++ compiler (cxx: x86_64-w64-mingw32-g++) ... no
error: ...mdir\core\sandbox\modules\import\core\base\scheduler.lua:47: cannot get program for cxx
stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:792: in function 'raise'
        ...mdir\core\sandbox\modules\import\core\base\scheduler.lua:47: in function 'co_start_named'
        @programdir\modules\private\async\runjobs.lua:180: in function <@programdir\modules\private\async\runjobs.lua:139>
        [C]: in function 'trycall'
        @programdir\core\base\scheduler.lua:423: in function 'co_group_begin'
        ...mdir\core\sandbox\modules\import\core\base\scheduler.lua:85: in function 'co_group_begin'
        @programdir\modules\private\async\runjobs.lua:139: in function 'runjobs'
        @programdir\actions\build\build.lua:222: in function 'build'
        @programdir\actions\build\main.lua:115: in function <@programdir\actions\build\main.lua:110>
        [C]: in function 'trycall'
        @programdir\core\sandbox\modules\try.lua:121: in function 'try'
        @programdir\actions\build\main.lua:109: in function <@programdir\actions\build\main.lua:82>
        [C]: in function 'load'
        @programdir\core\base\task.lua:520: in function 'run'
        @programdir\core\main.lua:282: in function 'cotask'
        @programdir\core\base\scheduler.lua:317: in function <@programdir\core\base\scheduler.lua:315>

@RoyiAvital
Copy link
Author

OK. It seems to work as expected.

@waruqi waruqi closed this as completed Oct 8, 2020
@RoyiAvital
Copy link
Author

It seems the issue us back.
This is my path:

Path=D:\Applications\MinGW\bin;D:\Applications\BuildEnv\CMake\bin\;D:\Applications\BuildEnv\Meson\;D:\Applications\BuildEnv\Ninja;D:\Applications\BuildEnv\Xmake;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\Royi\AppData\Local\Microsoft\WindowsApps;

I run and get:

D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake f -p mingw
checking for architecture ... x86_64
checking for mingw directory ... no
please run:
    - xmake config --mingw=xxx
or  - xmake global --mingw=xxx

Why doesn't it infer MinGW automatically as it did previously?

@waruqi
Copy link
Member

waruqi commented Sep 22, 2021

I did not change it, you can debug this patch.

if not sdkdir then
local pathenv = os.getenv("PATH")
if pathenv then
for _, p in ipairs(path.splitenv(pathenv)) do
if p:find(string.ipattern("mingw[%w%-%_%+]*[\\/]bin")) and path.filename(p) == "bin" and os.isdir(p) then
sdkdir = path.directory(p)
break
end
end
end
end
end

@RoyiAvital
Copy link
Author

RoyiAvital commented Sep 22, 2021

I don't know how to debug this.
I just know it doesn't work and probably the issue isn't there.

Is there any more information I can add?
This is the main feature of xmake for me.
Easy to configure.

This is what I get:

D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake f -p mingw -Dv -c

checking for architecture ... x86_64
checking for mingw directory ... no
please run:
    - xmake config --mingw=xxx
or  - xmake global --mingw=xxx
error: @programdir\core\main.lua:279: @programdir\core\tool\toolchain.lua:255: stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:840]: in function 'raise'
    [@programdir\toolchains\mingw\check.lua:49]:
    [C]: in function 'load'
    [@programdir\core\tool\toolchain.lua:251]: in function 'check'
    [@programdir\core\platform\platform.lua:247]: in function 'check'
    [@programdir\actions\config\main.lua:384]:
    [C]: in function 'load'
    [@programdir\core\base\task.lua:519]: in function 'run'
    [@programdir\core\main.lua:277]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:365]:

stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:829: in function 'raise'
        @programdir\core\main.lua:279: in function 'cotask'
        @programdir\core\base\scheduler.lua:365: in function <@programdir\core\base\scheduler.lua:362>

@waruqi
Copy link
Member

waruqi commented Sep 22, 2021

edit your installed xmake/xmake/modules/detect/sdks/find_mingw.lua in c:programdir/xmake

Add some print logs to debug it.

             for _, p in ipairs(path.splitenv(pathenv)) do 
                 print(p, os.isdir(p)) ---> debug log
                 if p:find(string.ipattern("mingw[%w%-%_%+]*[\\/]bin")) and path.filename(p) == "bin" and os.isdir(p) then 
                     print("found", p) --> debug log
                     sdkdir = path.directory(p) 
                     break 
                 end 
             end 

@RoyiAvital
Copy link
Author

Bu as I wrote above, even if I set the folder path explicitly with --mingw=D:\Applications\MinGW\bin I get the same error.
So I'm not sure it is the path finding but something else.

As I wrote on Gitter, I'm on a computer without Visual Studio installed.
I have no problems compiling the project with CMake.

@RoyiAvital
Copy link
Author

This is what I get after adding your debug commands:

D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake f -p mingw -Dv -c
checking for architecture ... x86_64
D:\Applications\BuildEnv\Xmake true
D:\Applications\MinGW\bin true
found D:\Applications\MinGW\bin
checking for mingw directory ... no
please run:
    - xmake config --mingw=xxx
or  - xmake global --mingw=xxx
error: @programdir\core\main.lua:279: @programdir\core\tool\toolchain.lua:255: stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:840]: in function 'raise'
    [@programdir\toolchains\mingw\check.lua:49]:
    [C]: in function 'load'
    [@programdir\core\tool\toolchain.lua:251]: in function 'check'
    [@programdir\core\platform\platform.lua:247]: in function 'check'
    [@programdir\actions\config\main.lua:384]:
    [C]: in function 'load'
    [@programdir\core\base\task.lua:519]: in function 'run'
    [@programdir\core\main.lua:277]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:365]:

stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:829: in function 'raise'
        @programdir\core\main.lua:279: in function 'cotask'
        @programdir\core\base\scheduler.lua:365: in function <@programdir\core\base\scheduler.lua:362>

@waruqi
Copy link
Member

waruqi commented Sep 22, 2021

Can you let me see your all mingw bin files list in D:\Applications\MinGW\bin

@RoyiAvital
Copy link
Author

RoyiAvital commented Sep 22, 2021

There you go:

D:\Applications\MinGW\bin>dir
 Volume in drive D has no label.
 Volume Serial Number is 121E-FA90

 Directory of D:\Applications\MinGW\bin

11/27/2019  12:24 PM    <DIR>          .
11/27/2019  12:24 PM    <DIR>          ..
02/20/2019  02:00 PM           108,074 7-zip.chm
02/21/2019  07:00 PM         1,679,360 7z.dll
02/21/2019  07:00 PM           468,992 7z.exe
02/21/2019  07:00 PM           205,824 7z.sfx
02/21/2019  07:00 PM           186,880 7zCon.sfx
11/27/2019  09:16 AM         1,157,632 addr2line.exe
11/27/2019  09:16 AM         1,186,304 ar.exe
11/27/2019  09:16 AM         1,926,656 as.exe
11/27/2019  09:16 AM         1,156,096 c++filt.exe
11/27/2019  12:07 PM         1,204,224 cpp.exe
11/27/2019  09:16 AM         1,218,560 dlltool.exe
11/27/2019  09:16 AM            56,832 dllwrap.exe
11/27/2019  09:16 AM            43,008 elfedit.exe
11/27/2019  12:07 PM         1,205,760 g++.exe
11/27/2019  12:07 PM            63,488 gcc-ar.exe
11/27/2019  12:07 PM            62,976 gcc-nm.exe
11/27/2019  12:07 PM            62,976 gcc-ranlib.exe
11/27/2019  12:07 PM         1,203,200 gcc.exe
11/27/2019  12:07 PM           585,728 gcov-dump.exe
11/27/2019  12:07 PM           646,144 gcov-tool.exe
11/27/2019  12:07 PM           861,184 gcov.exe
11/27/2019  09:55 AM         7,528,448 gdb.exe
11/27/2019  09:55 AM           558,592 gdbserver.exe
11/27/2019  09:16 AM         1,228,288 gprof.exe
11/27/2019  10:02 AM           800,768 grep.exe
11/27/2019  10:04 AM           515,584 jpegtran.exe
11/27/2019  10:04 AM           504,832 lame.exe
11/27/2019  09:16 AM         1,673,216 ld.bfd.exe
11/27/2019  09:16 AM         1,673,216 ld.exe
11/27/2019  10:06 AM           225,280 make.exe
11/27/2019  10:06 AM           225,280 mingw32-make.exe
11/27/2019  09:16 AM         1,170,432 nm.exe
11/27/2019  09:16 AM         1,298,432 objcopy.exe
11/27/2019  09:16 AM         2,575,872 objdump.exe
11/27/2019  12:19 PM           304,640 oggdec.exe
11/27/2019  12:19 PM           889,344 oggenc.exe
11/27/2019  12:19 PM           287,232 ogginfo.exe
11/27/2019  12:07 PM           436,224 optipng.exe
11/27/2019  12:11 PM           630,272 pcre2grep.exe
11/27/2019  12:11 PM         1,890,816 pcre2test.exe
11/27/2019  12:09 PM           519,168 pcregrep.exe
11/27/2019  12:09 PM         1,515,520 pcretest.exe
11/27/2019  12:11 PM           116,224 pngcheck.exe
11/27/2019  09:16 AM         1,186,304 ranlib.exe
11/27/2019  09:16 AM           879,616 readelf.exe
11/27/2019  12:23 PM           266,240 sed.exe
11/27/2019  09:16 AM         1,159,168 size.exe
11/27/2019  09:33 AM           223,744 sort.exe
11/27/2019  09:16 AM         1,158,144 strings.exe
11/27/2019  09:16 AM         1,298,432 strip.exe
11/27/2019  09:33 AM           140,800 uniq.exe
11/27/2019  12:24 PM           879,104 unzstd.exe
11/27/2019  12:19 PM           272,384 vcut.exe
11/27/2019  12:19 PM           287,232 vorbiscomment.exe
11/27/2019  09:33 AM           145,408 wc.exe
11/27/2019  09:16 AM         1,182,720 windmc.exe
11/27/2019  09:16 AM         1,284,096 windres.exe
11/27/2019  12:24 PM           879,104 zstd.exe
11/27/2019  12:24 PM           879,104 zstdcat.exe
11/27/2019  12:24 PM           879,104 zstdmt.exe

It is the current distribution form https://github.com/StephanTLavavej/mingw-distro (Version 17.1).

@waruqi
Copy link
Member

waruqi commented Sep 22, 2021

x86_64-w64-mingw32-gcc and all bin files with x86_64-w64-mingw32- not found

if not cross then
if is_arch("i386", "x86", "i686") then
cross = "i686-w64-mingw32-"
elseif is_arch("arm64", "aarch64") then
cross = "aarch64-w64-mingw32-" -- for llvm-mingw
elseif is_arch("arm.*") then
cross = "armv7-w64-mingw32-" -- for llvm-mingw
else
cross = "x86_64-w64-mingw32-"
end
end

@RoyiAvital
Copy link
Author

Well, They are not needed. Why did you put them in the list of required?

As I wrote, I can easily create the project with CMake and Meson so if XMake requires something extra, it is advised to not.
Moreover, I am no doing cross. I am on Windows and generating native Windows Binary / DLL.

@SirLynix
Copy link
Member

@waruqi Some MinGW distributions don't have x86_64-w64-mingw32-gcc.exe and have gcc.exe instead, I've worked with some in the past. XMake should probably fallback on them

@waruqi
Copy link
Member

waruqi commented Sep 22, 2021

I have improved it, try it again.

@RoyiAvital
Copy link
Author

Could you tag a release?
Also, those tests were not there when we created this automatic MinGW support. Why did you add them?

@waruqi
Copy link
Member

waruqi commented Sep 22, 2021

Could you tag a release?

Not yet. There are still many issues and features that need to be dealt with. You need to wait for a while.

Also, those tests were not there when we created this automatic MinGW support. Why did you add them?

what tests?

@RoyiAvital
Copy link
Author

The tests for those file names.
Why did you add them?

Do you have a unit test before release.
You should add the distribution I linked above. It is probably the most used on Windows and XMake fails on it unlike Meson and CMake.

@waruqi
Copy link
Member

waruqi commented Sep 23, 2021

The tests for those file names.
Why did you add them?

Do you have a unit test before release.
You should add the distribution I linked above. It is probably the most used on Windows and XMake fails on it unlike Meson and CMake.

for supporting llvm-mingw and mingw on msys, mingw on macos.

On msys, gcc.exe may not be mingw gcc, and llvm-mingw provides other arch support.

The unit test of the tool chain is too heavyweight, and it is impossible to test all tool chains and all cases on ci. And currently, basic tests have been done on the msys/mingw and macos/mingw tool chains on ci.

@RoyiAvital
Copy link
Author

OK, so it went too far. On Windows, without MSYS2 no need to check those.
For the extreme cases of Cross Compilation you removed support for the basic case of MinGW on Windows.

@waruqi
Copy link
Member

waruqi commented Sep 23, 2021

OK, so it went too far. On Windows, without MSYS2 no need to check those.
For the extreme cases of Cross Compilation you removed support for the basic case of MinGW on Windows.

I did not delete it, because I have never supported gcc.exe for mingw in the previous version

@RoyiAvital
Copy link
Author

I can assure you that version 2.3.8 worked with the MinGW distribution I am using and did find MinGW correctly.
You may see my comment #977 (comment). It worked.

@waruqi
Copy link
Member

waruqi commented Sep 23, 2021

same code in v2.3.8

if not cross then
if is_arch("i386", "x86", "i686") then
cross = "i686-*-"
elseif is_arch("arm64", "aarch64") then
cross = "aarch64-*-" -- for llvm-mingw
elseif is_arch("arm.*") then
cross = "armv7-*-" -- for llvm-mingw
else
cross = "x86_64-*-"
end
end
-- find cross toolchain
local toolchain = find_cross_toolchain(sdkdir or bindir, {bindir = bindir, cross = cross})
if toolchain then
return {sdkdir = toolchain.sdkdir, bindir = toolchain.bindir, cross = toolchain.cross}
end
end

@RoyiAvital
Copy link
Author

RoyiAvital commented Sep 23, 2021

I think things are not well tested and hence things break up without your awareness at all.
This is 2.3.8:

D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake f -p mingw -v
checking for architecture ... x86_64
checking for mingw directory ... D:\Applications\MinGW
checking for x86_64-w64-mingw32-g++ ... no
checking for the shared library linker (sh: x86_64-w64-mingw32-g++) ... no
checking for x86_64-w64-mingw32-gcc ... no
checking for the shared library linker (sh: x86_64-w64-mingw32-gcc) ... no
checking for D:\Applications\MinGW\bin\g++ ... ok
checking for the shared library linker (sh) ... g++
configure
{
    cross =
    buildir = build
    ccache = true
    host = windows
    mode = release
    mingw = D:\Applications\MinGW
    kind = static
    ndk_stdcxx = true
    arch = x86_64
    plat = mingw
    bin = D:\Applications\MinGW\bin
}

D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake -v -w
checking for the c compiler (cc: x86_64-w64-mingw32-gcc) ... no
checking for D:\Applications\MinGW\bin\gcc ... ok
checking for the c compiler (cc) ... gcc
checking for flags (-Ofast) ... ok
checking for flags (-mavx2) ... ok
checking for flags (-march=native) ... ok
checking for flags (-mx32) ... ok
checking for ccache ... no
[ 50%]: compiling.release IncompleteCholeskyDecomposition.c
D:\Applications\MinGW\bin\gcc -c -m64 -Wall -Wextra -Weffc++ -Ofast -mavx2 -std=c17 -march=native -mx32 -o build\.objs\IncompleteCholeskyDecomposition\mingw\x86_64\release\IncompleteCholeskyDecomposition.c.obj IncompleteCholeskyDecomposition.c
checking for flags (-MMD -MF) ... ok
checking for flags (-fcolor-diagnostics) ... no
checking for flags (-fdiagnostics-color=always) ... ok
error: cc1.exe: warning: command line option '-Weffc++' is valid for C++/ObjC++ but not for C
cc1.exe: error: '-mabi=ms' not supported with X32 ABI

As you can see, it works (The error has to do with the xmake.lua not written well).

So maybe there are more issues and the code you pointed to isn't the one affecting this.
It makes XMake look fragile and not well tested as it seems many things are done without measuring all consequences with unit testing.

I think you need to recheck the changes.

@RoyiAvital
Copy link
Author

RoyiAvital commented Sep 23, 2021

I fixed the xmake.lua file and everything works:

D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake -v -w
checking for D:\Applications\MinGW\bin\gcc ... ok
checking for flags (-Ofast) ... ok
checking for flags (-mavx2) ... ok
checking for flags (-march=native) ... ok
checking for ccache ... no
[ 50%]: compiling.release IncompleteCholeskyDecomposition.c
D:\Applications\MinGW\bin\gcc -c -m64 -Wall -Wextra -Weffc++ -Ofast -mavx2 -std=c17 -march=native -o build\.objs\IncompleteCholeskyDecomposition\mingw\x86_64\release\IncompleteCholeskyDecomposition.c.obj IncompleteCholeskyDecomposition.c
checking for flags (-MMD -MF) ... ok
checking for flags (-fcolor-diagnostics) ... no
checking for flags (-fdiagnostics-color=always) ... ok
cc1.exe: warning: command line option '-Weffc++' is valid for C++/ObjC++ but not for C
[ 75%]: linking.release IncompleteCholeskyDecomposition.dll
D:\Applications\MinGW\bin\g++ -o build\mingw\x86_64\release\IncompleteCholeskyDecomposition.dll build\.objs\IncompleteCholeskyDecomposition\mingw\x86_64\release\IncompleteCholeskyDecomposition.c.obj -shared -m64 -s -Wl,--out-implib,build\mingw\x86_64\release\IncompleteCholeskyDecomposition.lib
[100%]: build ok!

Now you see you have made changes since 2.3.8 which destroyed this feature?

By the way, using the flag -Weffc++ on a C project is wrong (I defined set_languages("c17") and all files are .c).

@waruqi
Copy link
Member

waruqi commented Sep 23, 2021

here.

        -- find tool path
+        if not opt.cross then
            toolpath = find_file(toolname, bindirs)
            if toolpath then
                return path.directory(toolpath), ""
            end
        end
+    end

    -- attempt to use the bin directory
    local bindir = opt.bindir or path.join(sdkdir, "bin")
+    if os.isdir(bindir) and not opt.cross then
        return bindir
+    end

Although this change affects mingw, I think this is the correct change.

In addition, the patch submitted in dev should have fixed your problem yesterday, there is no need to modify anything.

I have improved it, try it again.

3a8aab0

@waruqi
Copy link
Member

waruqi commented Sep 23, 2021

By the way, using the flag -Weffc++ on a C project is wrong (I defined set_languages("c17") and all files are .c).

I have removed it.

@RoyiAvital
Copy link
Author

Is this fixed in the latest release?

@waruqi
Copy link
Member

waruqi commented Oct 24, 2021

Please see the previous reply.

In addition, the patch submitted in dev should have fixed your problem yesterday, there is no need to modify anything.

I have improved it, try it again.

3a8aab0

@RoyiAvital
Copy link
Author

I want to wait when it is on the official release.
Is it now? If not, when?

@SirLynix
Copy link
Member

XMake 2.5.8 was released two weeks ago (so after this change was made) and thus has this fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants