Am 24.09.2013 um 23:28 schrieb Eliot Miranda eliot.miranda@gmail.com:
Hi Tobias,
On Tue, Sep 24, 2013 at 2:13 PM, Tobias Pape Das.Linux@gmx.de wrote:
Dear Eliot, all
Am 24.09.2013 um 20:16 schrieb Eliot Miranda eliot.miranda@gmail.com:
Thanks Marcel!! Can I fold this into my makefiles?
Is gcc 3 really necessary for Cog? “yes” clearly is a proper answer, but last year, as I had to fiddle with the Self VM and make it compile, even Old gcc4 were a pain.
All I wanted to do was to thank Marcel for his advice on setting up a functional build environment, and include whatever parts of that were relevant.
Yes. I should make a pause to emphasize this, too. mea culpa.
I am actually trying to use gcc 4 for cygwin but this is on the back burner because the win32api headers in latest cygwin releases were damaged when last I tried to build (it appears someone has supplied the 64-bit version in the 32-bit context, grr...).
Sounds painful.
I tried to set up the Makefile to select either gcc3 or gcc4 depending on cygwin version. I was doing this primarily to build a correct SqueakSSL plugin, which would not build with the older win32 api in the older gcc3-based cygwin I've been using since 2009. Alas I failed to build using a more up-to-date cygwin. So you can imagine I was very pleased to see that Marcel had made progress.
Yes, I imagine. I was pretty excited, too, when he showed me that it works ;)
So IMO, no gcc 3 should *not* be necessary to build Cog. But a functional build environment is needed, and right now I don't have a funcitonal gcc4-based build environment :-(
Anyone who wants to try and fix this is very welcome. I can supply them with the Makefile that selects the appropriate gcc version. So far I have this in my not-yet-checked-in experimental Makefile:
# C compiler settings (gcc-3.4.4 cygwin 1.5.25(0.156/4/2) vs gcc-4.5.2 1.7.17(0.262/5/3)) # determine cygwin version using uname -r # # determine "old" (eg 1.5.25(0.156/4/2)) or "new" cygwin (eg 1.7.17(0.262/5/3)) ifeq ($(shell ls /usr/bin/i686-pc-mingw32-gcc.exe),/usr/bin/i686-pc-mingw32-gcc.exe) NEWMGW=true endif
ifdef NEWMGW CC:=i686-pc-mingw32-gcc else CC:=gcc endif
When I sat down with Marcel, we were at this point, too. It turned out, however, that the i686-pc-mingw32-gcc was not able to compile and link (or better, find the right paths and includes) the whole codebase. Marcel found a package providing an i686-w64-mingw32-gcc, which got further but eventually failed, too.
Ian apparently has done some tweaks to the build system
for the win32 branch[1]. It also uses MSYS and MinGW but probably more recent gcc'en (but I'm not sure)[2]. Just out of curiosity, have you sync'ed the cog-branch platform dir after the initial branching?
Not carefully. I try to merge when I see relevant changes going into trunk, but I've probably missed a few.
well, the whole cygwinbuild dir is gone and replaced…
Please do not regard me as a show stopper or „Spaßbremse“, but I figure, that the entry barrier to work with the Squeak VM or Cog is quite high, even if you don't want touch the interpreter/jit at all. We should make it more approachable.
+1000. But I need help. I don't have time to attend to this now :-(
If Marcel has a VM request again, and we have some time, we probably can figure out something, but alas, I cannot promis; university wants its time :)
I think Mariano did a good job for an introduction to building a Squeak/Cog VM[3], But his 2nd-level tool-chain (sources from gitorious+CMake via CMakeVMMaker)[4] seems vastly different from the current Makefile-based approach, but apparently, the CMake toolchain can make use of more recent compilers.
Where are we headed?
Onwards and upwards ;-)
We better should.
Personally I hate both autoconf and CMake, but better the devil you know, and have hence stuck with autoconf on unix. On Mac & cygwin I use ungenerated makefiles. I'm open to change but I don't want to do the work. If someone can help produce functional build environments I'll gladly try them out and fold them back in if they work. But they must work for the Squeak VM, the Squeak MT VM and the Newspeak VM. That's what I build across three platforms right now and I don't want to waste the cycles trying to get new stuff to work with no guarantee of success... Call me a cynic ;-)
Not cynic, but more pragmatic. But I think we will eventually reach a status of discomfort with either choices we face (think gcc3 vs gcc4 and so on) and then, we as a community have to decide. As for cmake vs autoconf vs…, when I worked on compiling the Self VM[1], I looked into several build systems. They all have their odds and ends, but in the end I figured, that they all need external tools apart from make, and cross-platform make is really painful. In the end I chose cmake because • learning a new language is not worse than for automake/conf/tools[2], gyp[3], or qmake[4] (haven't looked at tup[5]) • CMake can generate files for your preferred native Build environment (Xcode on OSX, VStudio on Win32, Eclipse…) and pure Makefiles, too. • cmake allows for integration with pkg-config to detect availability of libraries. • cmake can be used with GUIs/CUIs to pre-select configuration schemes (eg, shall I build a Cog/Stack/Interpreter? MT/non-MT? Pharo/Squeak- branded? Newspeak instruction set?) This is no advertising but my findings of that time. Either choice will fit me.
HTH
Best -Tobias
[1] I wrote about my findings of that time on http://blog.selflanguage.org/ My CMake stuff for self went here: https://github.com/krono/self/tree/cmake/vm/cmake [2] See https://www.gnu.org/savannah-checkouts/gnu/automake/manual/html_node/Autotoo... https://www.gnu.org/software/automake/ I personally think the hodgepodge of autoconf syntax, automake syntax, and loads of template files, and M4, make this choice as approachable as the Mt Everest for a 5 year old [3] See https://code.google.com/p/gyp/ Used by Chromium and v8 to overcome certain problems the authors had with cmake. The syntax (https://code.google.com/p/gyp/wiki/GypLanguageSpecification) essentially is JSON with special keyword (or s-expressions, if you want) [4] http://qt-project.org/wiki/Category:Tools::qmake, http://qt-project.org/doc/qt-5.0/qtdoc/qmake-manual.html It bears resemblance with cmake but really makes only sense when using Qt. [5] http://gittup.org/tup/ I don't know it but Chis Double (http://double.co.nz/, http://bluishcoder.co.nz/) does.