Automatic Inference of `MinGW` SDK Directory #977

RoyiAvital · 2020-10-03T13:39:44Z

The code in:

xmake/xmake/modules/detect/sdks/find_mingw.lua

Lines 30 to 43 in c1f1db8

    
           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):

If on Windows, Look for Environment Variables GCC_BIN_PATH or GCC_LIB_PATH.
In case they exist define minGwSdk = GCC_BIN_PATH/.. or minGwSdk = GCC_LIB_PATH/.. with priority for the BIN folder.
If not on Windows, do as the code above deines.
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.

The text was updated successfully, but these errors were encountered:

waruqi · 2020-10-03T13:55:39Z

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 · 2020-10-03T14:16:21Z

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

For instance, its content is:

waruqi · 2020-10-03T14:26:19Z

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 · 2020-10-03T14:47:02Z

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 · 2020-10-03T15:07:48Z

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 · 2020-10-03T15:13:24Z

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 · 2020-10-03T15:15:08Z

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 · 2020-10-03T15:17:19Z

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 · 2020-10-03T15:23:22Z

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 · 2020-10-03T15:35:50Z

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 · 2020-10-03T15:42:46Z

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 · 2020-10-03T18:02:39Z

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:

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 · 2020-10-05T05:20:04Z

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

xmake update dev

waruqi · 2020-10-05T05:46:56Z

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 · 2020-10-07T02:08:51Z

Does it work?

RoyiAvital · 2020-10-07T06:36:32Z

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

waruqi · 2020-10-07T06:42:23Z

you can download install package from action ci.

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

RoyiAvital · 2020-10-07T07:03:28Z

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 · 2020-10-07T07:07:31Z

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

xmake f -p mingw -Dv -c

RoyiAvital · 2020-10-07T07:12:08Z

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 · 2020-10-07T07:14:04Z

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

RoyiAvital · 2020-10-07T07:23:03Z

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

waruqi · 2020-10-07T07:34:47Z

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 · 2020-10-07T08:38:46Z

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

waruqi · 2020-10-07T08:52:57Z

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 · 2020-10-07T11:09:21Z

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 · 2020-10-08T05:38:42Z

OK. It seems to work as expected.

RoyiAvital · 2021-09-22T12:28:15Z

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 · 2021-09-22T12:33:08Z

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

xmake/xmake/modules/detect/sdks/find_mingw.lua

Lines 48 to 59 in 5e4fd84

    
               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 · 2021-09-22T12:39:36Z

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 · 2021-09-22T13:40:11Z

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 · 2021-09-22T13:42:23Z

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 · 2021-09-22T13:45:25Z

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 · 2021-09-22T13:54:17Z

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

RoyiAvital · 2021-09-22T14:16:17Z

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 · 2021-09-22T14:23:05Z

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

xmake/xmake/modules/detect/sdks/find_mingw.lua

Lines 83 to 93 in 85283fa

    
           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 · 2021-09-22T14:30:02Z

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 · 2021-09-22T14:33:58Z

@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 · 2021-09-22T14:54:14Z

I have improved it, try it again.

RoyiAvital · 2021-09-22T19:50:36Z

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

waruqi · 2021-09-22T23:47:25Z

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 · 2021-09-23T04:36:24Z

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 · 2021-09-23T04:54:08Z

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 · 2021-09-23T05:07:10Z

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 · 2021-09-23T05:16:20Z

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 · 2021-09-23T06:25:57Z

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 · 2021-09-23T06:34:48Z

same code in v2.3.8

xmake/xmake/modules/detect/sdks/find_mingw.lua

Lines 83 to 100 in 965bccf

    
               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 · 2021-09-23T12:21:31Z

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 · 2021-09-23T12:33:06Z

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 · 2021-09-23T12:50:58Z

here.

xmake/xmake/modules/detect/sdks/find_cross_toolchain.lua

Line 46 in 6708849

if not opt.cross then

        -- 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 · 2021-09-23T12:57:57Z

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 · 2021-10-24T12:37:51Z

Is this fixed in the latest release?

waruqi · 2021-10-24T13:02:38Z

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 · 2021-10-24T17:53:14Z

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

SirLynix · 2021-10-24T18:26:57Z

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

waruqi added this to the v2.3.8 milestone Oct 3, 2020

waruqi added feature request improvement labels Oct 3, 2020

RoyiAvital mentioned this issue Oct 7, 2020

Order of Toolchain Flags and User Flags in Compilation Process #978

Closed

waruqi closed this as completed Oct 8, 2020

Automatic Inference of MinGW SDK Directory #977

Automatic Inference of MinGW SDK Directory #977

Comments

RoyiAvital commented Oct 3, 2020

waruqi commented Oct 3, 2020

RoyiAvital commented Oct 3, 2020 • edited Loading

waruqi commented Oct 3, 2020

RoyiAvital commented Oct 3, 2020

waruqi commented Oct 3, 2020 • edited Loading

RoyiAvital commented Oct 3, 2020

waruqi commented Oct 3, 2020

waruqi commented Oct 3, 2020

RoyiAvital commented Oct 3, 2020

waruqi commented Oct 3, 2020

RoyiAvital commented Oct 3, 2020

RoyiAvital commented Oct 3, 2020 • edited Loading

Update

waruqi commented Oct 5, 2020

waruqi commented Oct 5, 2020

waruqi commented Oct 7, 2020

RoyiAvital commented Oct 7, 2020

waruqi commented Oct 7, 2020

RoyiAvital commented Oct 7, 2020

waruqi commented Oct 7, 2020

RoyiAvital commented Oct 7, 2020

waruqi commented Oct 7, 2020

RoyiAvital commented Oct 7, 2020

waruqi commented Oct 7, 2020

RoyiAvital commented Oct 7, 2020

waruqi commented Oct 7, 2020

RoyiAvital commented Oct 7, 2020

RoyiAvital commented Oct 8, 2020

RoyiAvital commented Sep 22, 2021

waruqi commented Sep 22, 2021

RoyiAvital commented Sep 22, 2021 • edited Loading

waruqi commented Sep 22, 2021

RoyiAvital commented Sep 22, 2021

RoyiAvital commented Sep 22, 2021

waruqi commented Sep 22, 2021

RoyiAvital commented Sep 22, 2021 • edited Loading

waruqi commented Sep 22, 2021 • edited Loading

RoyiAvital commented Sep 22, 2021

SirLynix commented Sep 22, 2021

waruqi commented Sep 22, 2021

RoyiAvital commented Sep 22, 2021

waruqi commented Sep 22, 2021

RoyiAvital commented Sep 23, 2021

waruqi commented Sep 23, 2021 • edited Loading

RoyiAvital commented Sep 23, 2021

waruqi commented Sep 23, 2021

RoyiAvital commented Sep 23, 2021

waruqi commented Sep 23, 2021 • edited Loading

RoyiAvital commented Sep 23, 2021 • edited Loading

RoyiAvital commented Sep 23, 2021 • edited Loading

waruqi commented Sep 23, 2021

waruqi commented Sep 23, 2021

RoyiAvital commented Oct 24, 2021

waruqi commented Oct 24, 2021

RoyiAvital commented Oct 24, 2021

SirLynix commented Oct 24, 2021

Automatic Inference of `MinGW` SDK Directory #977

Automatic Inference of `MinGW` SDK Directory #977

RoyiAvital commented Oct 3, 2020 •

edited

Loading

waruqi commented Oct 3, 2020 •

edited

Loading

RoyiAvital commented Oct 3, 2020 •

edited

Loading

RoyiAvital commented Sep 22, 2021 •

edited

Loading

RoyiAvital commented Sep 22, 2021 •

edited

Loading

waruqi commented Sep 22, 2021 •

edited

Loading

waruqi commented Sep 23, 2021 •

edited

Loading

waruqi commented Sep 23, 2021 •

edited

Loading

RoyiAvital commented Sep 23, 2021 •

edited

Loading

RoyiAvital commented Sep 23, 2021 •

edited

Loading