On Sat, 26 Nov 2016 23:16:50 +0100, Ronie Salgado <[email protected]>
wrote:
Hi,
I am fighting Window VM compilation issues (e.g. Cairo with GCC5.x
under Mingw).
If you have a GCC5 instead of the old 4.6, I am interested in your
config.
Now I am building in Windows using both, MinGW version 4.9.3, and Visual
Studio 2015 Community Edition.
I got working pharo,exe -headless Pharo-minimal.image eval "1+1" (the
-headless parameter is for the image to quit after finishing).
When running a normal Pharo.image, I am getting a FFI related crash
(with Visual Studio and MinGW), when the image tries to read the APPDATA
environment variable.
Right now I am using the same main function for both, the Unix and Win32
VM. This means, that we are close of having the embedded version.
I love that :)
In windows I am build two variants of the VM, pharo.exe (or squeak.exe)
and pharow.exe (or squeakw.exe). The executable without the w is a
console program, so it can >use stdin, stdout and stderr. The executable
with the w is a windows program that does not create a console window on
startup, but it cannot use stdout, stderr, or stdin. >This is the
standard workaround for an annoying limitation of Windows itself (Python
does the same in windows, with the same nomenclature).
Yes this is on the roadmap of esteban but he got killed by vm merge + UFFI
Visual Studio is unstable than MinGW, but it has an excellent debugger.
With Visual Studio, I am getting some false positives for an assertion
because they get >miscompiled. For some reason, the
assert(GIV(remapBufferCount) == 0) gets compiled into the same as
assert(GIV(remapBufferCount)). Apart from this assertion, these >two
versions of the VM are crashing in the same place.
Fantastic, except:
- Unified standard CMake building scripts for Unixes. I hate autoconf.
I want to use them in Windows too.
We have agreed that we will use makefiles and restrict make to
generating platform config.h files that define platform facilities. I
have very good reasons for doing this. I >>have discussed this at
length this year. Please don't make me argue this all over again.
...
[goodness deleted]
I cannot just use makefile, because I am also compiling in Windows using
Visual Studio 2015 Community Edition, by generating the visual studio
projects with CMake. I >looked for the older discussions on the mailing
lists, I could not find, a long discussion on the mailing list, except
for several short ones.
I have also seen some projects(LLVM, Boost) that have more than one
build system, an official based on autoconf(or something else), and an
alternative based on CMake.
As for the config.h, I can also generate it using CMake, and I will
start doing it now because I think that it is related to the FFI
crashing issues that I am experimenting on >Windows. Currently I am
already using CMake for generating the git version string. As long as
git is in the path and cmake founds it, the header with the version
string is >generated correctly, even when using the Visual Studio
projects.
Anyway, I am not using the old CMakeVMMaker that Igor did(and I just
learned about Ian CMake work by finding in the mailing list). I just
adapted the plain CMake scripts >that I normally use for building my own
projects to build the VM.
Are you on board? Would you like to discuss this on skype or
somewhere?
Sure we can discuss it, I am on chile so we are not far apart in time
zones.
As long as building the VM can be done automatically in Unixes by
running a short number of commands, that work most of the time, I am OK
with it.
As for Windows, it has to be possible to use Visual Studio in addition
to MinGW or Cygwin. Visual Studio is required to be able to build for
the Universal Windows Platform, >and getting the VM working in a retail
XBox One ( https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/index
).
Best regards,
Ronie
2016-11-26 14:09 GMT-03:00 Eliot Miranda <[email protected]>:
Hi Roni,
On Nov 23, 2016, at 11:12 PM, Ronie Salgado <[email protected]> wrote:
Hello,
I am working on removing most of windowing code from the VM, and in
trying to unify the platform specific code of the VM. In the
MinimalistHeadless >>>branch of
https://github.com/ronsaldo/opensmalltalk-vm I made the following
changes:
Fantastic, except:
- Unified standard CMake building scripts for Unixes. I hate autoconf.
I want to use them in Windows too.
We have agreed that we will use makefiles and restrict make to
generating platform config.h files that define platform facilities. I
have very good reasons for doing this. I >>have discussed this at
length this year. Please don't make me argue this all over again. Are
you on board? Would you like to discuss this on skype or somewhere?
...
[goodness deleted]
Does it make sense, to always trying to create a display in startup
time?
Good question. The answer should be "no" but that only makes sense if
the system is written to not depend on a display when in headless mode.
Best regards,
Ronie
--
Using Opera's mail client: http://www.opera.com/mail/
