Those assumptions are all correct. Looking at your other mail, I think I
understand what might be going wrong here.
My guess is that you either tried to use PLATFORM=mingw from an msys
shell (i.e., msys2 bash), which would explain the error about XCOPY,
or you used PLATFORM=... with make, then aborted the compilation and
then switched to a different PLATFORM.
I always ran clean/confclean between any builds to regenerate the chicken-config file and would
watch for its generation when I built it, so I don't think it was that.
I'm pretty sure I never mixed and matched PLATFORM= values between runs, and never ran
just "mingw".
That won't work because the
PLATFORM is written into chicken-config.h. So it may appear to work
because the build works fine, but the resulting binaries will have
settings wired into them that don't match the platform you're building
for.
The steps I outlined above were from clean installs, and cleaning between runs.
I even did a local git commit from the original tarball to ensure I wasn't amending
anything I wasn't expecting.
Be sure to run the make from the type of shell you want to run the
resulting binaries from. So mingw-msys from a bash prompt if you
want to use CHICKEN from msys' bash prompt, or plain mingw from a
Windows CMD prompt if you want to use CHICKEN from that.
This is exactly what I was expecting too, although the "mingw-msys" build I would
expect to be from a "MSYS2 MinGW 64bit" shell to be specific (as opposed
to "MSYS2 MSYS" shell) when running make.
I never ran a build from a windows cmd shell, so I don't understand the file path/xcopy
errors. Interestingly this is one of the problems in the chocolatey build, it's using "cp" in
a windows cmd shell instead of xcopy.
> I found this site:
> https://github-wiki-see.page/m/accidentalrebel/rebel-game-engine/wiki/Building-and-running-the-engine-for-Windows-%28using-Msys2%29
This is really wrong and I have no idea who came up with this, but the
described actions are mixing up MSYS and Cygwin concepts.
Agreed, yet somehow the resultant binaries work fine, and I'm glad you've confirmed my "but it shouldn't"
thoughts. I've just checked my install out and it's got cyg*.dll files created, so I'm attempting a new build.
Also, I think the platform auto-detection ought to work with 5.3.0,
so you don't even need to pass in PLATFORM.
I only just came across the detect Makefile.
So, just running make on its own, with no PLATFORM (after running clean/confclean).
- - - run 1 MSYS2/MINGW64 shell - - -
shell = MSYS2/MINGW64
gcc=gcc.exe (Rev5, Built by MSYS2 project) 10.3.0
make=GNU Make 4.3, Built for x86_64-pc-msys
make clean confclean
touch *.scm # force rebuild of c files
make
make DESTDIR=/tmp/chicken-build/001 install
The resultant binary has the following problem (which I've seen before but can't remember if I mentioned in this thread):
$ /tmp/chicken-build/001/usr/local/bin/chicken-install -update-db
loading import libraries ...
generating database ...
Error: (open-output-file) cannot open file - No such file or directory: "/usr/local/lib/chicken/11\\modules.db"
So it's mixing windows paths in.
- - - run MSYS2 shell - - -
shell = MSYS2
gcc=gcc (GCC) 10.2.0 # NOTE: This is different gcc
make=GNU Make 4.3, Built for x86_64-pc-msys
make clean confclean
touch *.scm # force rebuild of c files
make
...
gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES -c -Os -DC_BUILDING_LIBCHICKEN posixwin.c -o posixwin-static.o -I. -I./
posixwin.c:140:10: fatal error: direct.h: No such file or directory
140 | #include <direct.h>
|
So this is failing to build because of missing headers in the MSYS only environment
I tried installing the packages that have direct.h (but installs it in /opt) in them and clean/building, but still fails with the same error.
So currently, I still can't produce working binaries in the MINGW64/MSYS environment.
The `\\` seems to be the problem at the moment.