Nuke MSYS2

[jpgpng]

I managed to build and use cm3 without MSYS2. This turns out to be easier than you think.

Requirements: mingw64 + cmake + ninja, all added to Windows PATH and of course Python 3

In concierge.py (https://github.com/modula3/cm3/blob/master/scripts/concierge.py) at line 1538 commented out all of these lines to be something like this:

        # Special considerations for NT.
        #if self.config() == "AMD64_NT":
            #setup = setup + ["-A", "x64"]
        #elif self.config() == "I386_NT":
            #setup = setup + ["-A", "Win32"]

Reasons: Generator Ninja does not support platform specification, but platform x64 was specified. It's also true for NMake Makefiles.

Have to specify --target AMD64_MINGW to concierge.py otherwise it will default to AMD64_NT and error because of not found cl.exe.

So finally, the command is something like this:

python ..\cm3-dist\scripts\concierge.py install --prefix [where you want to install cm3] -G "Ninja" --target AMD64_MINGW

Now, this is about building from latest git source. On pylib.py (https://github.com/modula3/cm3/blob/master/scripts/python/pylib.py) at line 1862 commented out all of these lines to be something like this:

        #_SetupEnvironmentVariableAll(
            #"PATH",
            #["sh", "sed", "gawk", "make"],
            #os.path.join(SystemDrive, "msys", "1.0", "bin"))

Reasons: we are using mingw64 and we don't have msys 1.0 or any needs of msys 1.0.

Everything later is just straight forward.

@jaykrell @VictorMiasnikov

[jpgpng]

Note: Still have to delete these two lines in cm3.cfg and replace with hardcoded HOST and TARGET like https://github.com/modula3/cm3/issues/1029

Delete:

if not defined("HOST") HOST = "AMD64_MINGW" end
if not defined("TARGET") TARGET = HOST end

Replace with:

HOST = "AMD64_MINGW"
TARGET = HOST

Have to redo this after boot2.py as it overwrote cm3.cfg.

[jaykrell]

Thank you your extra work and reporting here. I will try to improve things. What you point out in pylib.py is a bit of a hack, I agree, and is hurting not helping. We can/should probably just remove those lines.

Host really shouldn't be needed in cm3.cfg. That is wierd. I have tiried to simplify cm3.cfg in general, and host/target specifically but it is possible this area needs more work.

Host really is supposed to be known by the executable itself, and it isn't even supposed to matter much. The main thing was to put forward or backward slashes in places, even though forward always work. Silly. There is a lot of legacy in the system. Like where host mattered too much. We have more work to do...

[VictorMiasnikov]

} 31.08.2022, 07:43, "jpgpng" @.***>:

Thank! Very well! We have fixed  concierge.py ( for AMD64_MINGW target)

(I'm on smartphone... Send as is...)

I managed to build and use cm3 without MSYS2. This turns out to be easier than you think.

Requirements: mingw64 + cmake + ninja, all added to Windows PATH and of course Python 3

In concierge.py (https://github.com/modula3/cm3/blob/master/scripts/concierge.py) at line 1538 commented out all of these lines to be something like this:

        # Special considerations for NT.
        #if self.config() == "AMD64_NT":
            #setup = setup + ["-A", "x64"]
        #elif self.config() == "I386_NT":
            #setup = setup + ["-A", "Win32"]

Reasons: Generator Ninja does not support platform specification, but platform x64 was specified. It's also true for NMake Makefiles.

Have to specify --target AMD64_MINGW to concierge.py otherwise it will default to AMD64_NT and error because of not found cl.exe.

So finally, the command is something like this:

python ..\cm3-dist\scripts\concierge.py install --prefix [where you want to install cm3] -G "Ninja" --target AMD64_MINGW

Now, this is about building from latest git source. On pylib.py (https://github.com/modula3/cm3/blob/master/scripts/python/pylib.py) at line 1862 commented out all of these lines to be something like this:

        #_SetupEnvironmentVariableAll(
            #"PATH",
            #["sh", "sed", "gawk", "make"],
            #os.path.join(SystemDrive, "msys", "1.0", "bin"))

Reasons: we are using mingw64 and we don't have msys 1.0 or any needs of msys 1.0.

Everything later is just straight forward.

@jaykrell @VictorMiasnikov

[jpgpng]

Update: build also fine with Clang (https://github.com/mstorsjo/llvm-mingw). But need editing pylib.py (https://github.com/modula3/cm3/blob/master/scripts/python/pylib.py) to comment out these lines (starting at line 1841) to be something like this:

        #_SetupEnvironmentVariableAll(
            #"PATH",
            #["gcc", "as", "ld"],
            #os.path.join(SystemDrive, "mingw", "bin"))

[VictorMiasnikov]

( Possible duplicate . . . )

Cm3 AMD64_NT can be build with clang.exe too ( "as information")

---

This document here said Visual Studio is needed. I don't want to install Visual Studio and GCC was said to be also supported so I want to use cm3 with GCC on my Windows. I'm using winlibs.com GCC build, but if MSYS2 is required I could install MSYS2 too.

https://github.com/modula3/cm3/wiki/Getting-Started%3A-Windows

+

{{

Winlibs.com GCC builds were designed to use with MSYS2 but if we are on MSYS2 why don't just use it GCC packages instead? Everything will be easier to be managed by just the pacman package manager. BTW, there seems to be a POSIX environment is needed so we will need MSYS2 (a distribution of MinGW-W64 alone like Winlibs.com's builds are not enough).

}}

} Visual Studio is needed

We are need some libs and "build tools" from / related Visual Studio for targets AMD64_NT, I386_NT. We can choice between cl.exe and clang.exe

} MSYS2 (a distribution of MinGW-W64

MinGW environment is need for targets AMD64_MINGW, I386_MINGW. ( 2022-08-31: ^^^^^^^^ I save text as "history artifact")

CygWin - for targets AMD64_CYGWIN, I386_CYGWIN

[jpgpng]

This Clang (https://github.com/mstorsjo/llvm-mingw) as it name tell you it's mingw based. It's different from the Clang you mentioned. AMD64_NT will always need MSVC.

[VictorMiasnikov]

31.08.2022, 20:14, "jpgpng" @.***>: This Clang (https://github.com/mstorsjo/llvm-mingw) as it name tell you it's mingw based. It's different from the Clang you mentioned. AMD64_NT will always need MSVC.

1) Microsoft Visual Studio 2022 - 2017 contain "itself clang.exe".

2) I compiled whole LLVM. Include clang.exe

And m3llvm.exe ( it is adapter (?) )

See in cm3 Pool Request LLVM10 and LLVM13 in "my release".

2b) We even have sub-error "GUI don't work when used clang.exe instead of cl.exe"

{{ ToDo: send URL to Issue and details 2022-09-01: Done, please see later }}

[VictorMiasnikov]

P.S.

I compiled LLVM 9.0.1 too ...

See near the bottom of https://github.com/modula3/cm3/issues/47

{{{ VictorMiasnikov commented May 18, 2021

In case compiling by clang-cl.exe from LLVM 9.0.1 by python upgrade.py && python do-cm3-all.py realclean skipgcc && python do-cm3-all.py buildship

and run Calculator.exe :

---

runtime error: An enumeration or subrange value was out of range. *** file "../src/winvbt/WinTrestle.m3", line 2115

---

. . . }}}

31.08.2022, 20:14, "jpgpng" @.***>: This Clang (https://github.com/mstorsjo/llvm-mingw) as it name tell you it's mingw based. It's different from the Clang you mentioned. AMD64_NT will always need MSVC.

[VictorMiasnikov]

31.08.2022, 20:14, "jpgpng" @.***>: This Clang (https://github.com/mstorsjo/llvm-mingw) as it name tell you it's mingw based. It's different from the Clang you mentioned. AMD64_NT will always need MSVC.

P.P.S. I known about LLVM-mingw Project. Looks like even download ( or going to download  -) )

[ghost]

Oh man, clang-cl is a completely different compiler to clang. Yes, it's clang under the hood and understand most of clang switches. It's indeed a modified clang to mimic cl.exe. The story is Microsoft's very own compiler cl.exe is too sucks and not as standard compliant as clang so they decided to wrap clang in clang-cl to support cl.exe switches. But, clang-cl and cl.exe are not completely compatible and clang-cl can't be used as a drop-in replacement for cl.exe. Proprietary vendors all did it when there own home grown compiler too sucks they fork open source ones, make them closed source (perfectly fine as llvm license allows that) and make wrappers like that. Borland (or now Embarcadero) did the same with bcc32c is the original compiler and bcc32 is the clang wrapper. Not just Microsoft.

[VictorMiasnikov]

Oh man, clang-cl is a completely different compiler to clang. Yes, it's clang under the hood and understand most of clang switches. It's indeed a modified clang to mimic cl.exe. The story is Microsoft's very own compiler cl.exe is too sucks and not as standard compliant as clang so they decided to wrap clang in clang-cl to support cl.exe switches. But, clang-cl and cl.exe are not completely compatible and clang-cl can't be used as a drop-in replacement for cl.exe. Proprietary vendors all did it when there own home grown compiler too sucks they fork open source ones, make them closed source (perfectly fine as llvm license allows that) and make wrappers like that. Borland (or now Embarcadero) did the same with bcc32c is the original compiler and bcc32 is the clang wrapper. Not just Microsoft.

It looks like we should "migrate" "Clang-cl sub-issue" to another ( new?) Issue . . .

ToDo: search it Or create

P.S. 2022-09-02:

} different between clang.exe and clang-cl.exe

It's interested topic, but best placed it inside dedicated issue ( or discussion)

[ghost]

It looks like we should "migrate" "Clang-cl sub-issue" to another ( new?) Issue . . .

ToDo: search it Or create

Oh nonsense man. I'm trying to explain to you the different between clang.exe and clang-cl.exe and it seems you are confused between the two. If you don't want it, I will shut up.