[Vm-dev] The insanity of using make for development builds
Todd Blanchard
tblanchard at mac.com
Fri Nov 30 23:58:06 UTC 2018
I noticed that lots of the platform plugins are also using CMake.
So our build system is kind of a patchwork I guess?
As a Mac/iOS guy I would LOVE to have a VM I can build in Xcode to tinker with using platform specific build tools. CMake will build Xcode projects or makefiles or lots of other kinds of build systems. Its kind of a build system builder and I like that.
I understand that it isn't going to be as fast as hand tuned build scripts like C isn't going to beat hand tuned assembly. But we sacrifice performance for understandability and flexibility when we can afford it.
Just my two cents on the build thing. I am finding the VM repository to be really hard to get my head around. So many parts. (And why is the Mac stuff in a directory below iOS but I can't find an iOS build target? Another thread, perhaps).
> On Nov 30, 2018, at 3:46 PM, Ronie Salgado <roniesalg at gmail.com> wrote:
>
> Hello,
>
> When I started making the minheadless version I wanted to nuke all of the platform specific code, and unify it as much as possible. For building I adapted the hand written CMake scripts that I normally use for my projects. One of my motivation for CMake is on using MSVC for building on Windows, which is also a requirement in order to support the UWP for running the VM in a retail Xbox One.
>
> Before folding back into opensmalltalk, Pharo actually had a CMake helper to build the VM with options etc.
> This was deemed too complicated and people steered towards a vanilla makefile.
> Pharo was NOT using CMake. Pharo was generating cmake scripts from the image, which then they were being used for compiling the VM. That is definitely a complicated and not a proper way of cmake.
>
> Now, yes, build times are long. But because there are a lot of dependencies being built as part of the whole.
> There are some optimisations yes, like not rebuilding, say, FreeType on every build.
> And also plugins. Many plugins do not make sense as being part of the VM. There are not properly maintained or used. In Pharo at least there is the tendency of moving as much functionality as out of the plugins, and replacing them with libraries that called via the FFI.
>
> Is is a pendulum swing in action?
> Well, with Esteban we decided one year ago that in order to reduce friction with the community, to use cmake only for configuration purpose (i.e replace autoconf to generate a config.h), and to keep using the existent makefiles. We already adapted the makefiles from Linux and Mac for Pharo. Handling dependencies during the build process is also another motivation for keeping the makefiles.
>
> As for me, I prefer to just use cmake for the whole build process. In my opinion, I think that we are suffering from the lack of proper separation between the core VM, and user specific features (e.g: freetype, cairo, midi, mp3 player, etc) that should be isolated as much as possible from the vm. The VM itself should be a virtual processor and memory manager, it should not be a full operating system with 3D graphics, joystick support, midi controller plugin interface. Those other features are not the responsibility of the VM.
>
> I just submitted a pull request that fixes the build with cygwin for win32 ( https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/311 <https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/311> ). During the weekend I will write proper documentation on how these cmake scripts are supposed to work. Normally it should just be a matter of issuing the following commands on the top-level directory:
>
> mkdir build
> cd build
> cmake ..
> make
>
> and then for development just use make, and some ocassional make clean. The scripts in build.minheadless.cmake are in place to automate this process and for building all of the variants of the vm. Cygwin is a bit trickier because it is treated as an Unix instead of Windows. Cygwin requires some additional command line options because it requires settings cmake in cross compilation mode by passing a toolchain file to cmake. The scripts in build.minheadless.cmake/x86|x64/<vm variant>/ already take care of detecting the usage of Cygwin, and passing the proper command line options to cmake.
>
> Best regards,
> Ronie
>
>
> El vie., 30 nov. 2018 a las 6:47, phil at highoctane.be <mailto:phil at highoctane.be> (<phil at highoctane.be <mailto:phil at highoctane.be>>) escribió:
>
>
>
> On Fri, Nov 30, 2018 at 8:55 AM Jakob Reschke <forums.jakob at resfarm.de <mailto:forums.jakob at resfarm.de>> wrote:
>
> Sorry, but it seems to me you criticize the shortcomings of cmake, but ignore its benefits.
>
> Of course, cmake expects that you are familiar with it to a certain degree and that you are familiar with your build definition (CMakeLists.txt), and thus, how and where to pull the right triggers. If you were unfamiliar with (your) Makefiles and make in general, wouldn't it be hard to find the correct place there, too?
>
> Before folding back into opensmalltalk, Pharo actually had a CMake helper to build the VM with options etc.
> This was deemed too complicated and people steered towards a vanilla makefile.
>
> And now what? Are we using CMake? I see that the log pertains to a headless version. So is it only for that one or is everything moving to CMake?
>
> In the the past, I had to use CMake 2.8 to get things to work because other versions were not working for some reason.
>
> Is is a pendulum swing in action?
>
> Now, yes, build times are long. But because there are a lot of dependencies being built as part of the whole.
> There are some optimisations yes, like not rebuilding, say, FreeType on every build.
>
> Now, we could be better by just having to core being rebuilt and assembled. But it is still C, so, change a header and bam, rebuild every bit.
>
> On speed, I never noticed that we were using something like https://ccache.samba.org/ <https://ccache.samba.org/> which may help.
>
> Best,
> Phil
>
>
>
>
> Looking at the generated Makefiles is the last resort when you suspect that there is a bug in cmake. Which should not be the default...
>
> The performance of the generated Makefiles is not optimal. That is not surprising IMHO because cmake must be able to support all varieties of build definitions and the cmake developers have to make compromises. You could try another generator and use Visual Studio, Ninja, or whatever for the build and see whether that works better for your development cycle. You cannot simply try that with hand-written Makefiles.
>
> Am Fr., 30. Nov. 2018 um 08:33 Uhr schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com <mailto:nicolas.cellier.aka.nice at gmail.com>>:
>
>
>
> Le ven. 30 nov. 2018 à 07:46, Norbert Hartl <norbert at hartl.name <mailto:norbert at hartl.name>> a écrit :
>
>
>
> Am 30.11.2018 um 01:38 schrieb Eliot Miranda <eliot.miranda at gmail.com <mailto:eliot.miranda at gmail.com>>:
>
>>
>>
>> On Thu, Nov 29, 2018 at 4:32 PM Eliot Miranda <eliot.miranda at gmail.com <mailto:eliot.miranda at gmail.com>> wrote:
>> thanks Todd,
>> On Thu, Nov 29, 2018 at 3:59 PM Todd Blanchard <tblanchard at mac.com <mailto:tblanchard at mac.com>> wrote:
>>
>> Don't know if this is helpful but maybe...
>>
>> https://stackoverflow.com/questions/2670121/using-cmake-with-gnu-make-how-can-i-see-the-exact-commands <https://stackoverflow.com/questions/2670121/using-cmake-with-gnu-make-how-can-i-see-the-exact-commands>
>>
>> I can really see what's going on now:
>>
>> BTW, that's 9.6 kb of text per compile command :-) One has to laugh, otherwise...
>>
> I have trouble to figure out what you are saying. First you complain you don‘t see enough. Then you complain there is too much? Is there a feasible amount of information generally or does it need your personal one?
>
> Norbert
>
> Hi Norbert,
> don't make it personal.
> it's like deugging a C code which would have been pre-processed with all include files and macros expanded.
> it is verbosity by repetition.
> it's not designed to be understandable.
> Definitely not the level of information fitting human capabilities.
>
> Nicolas
>>
>> make -C debug all
>> make[1]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>> /usr/bin/cmake.exe -H/cygdrive/z/oscogvm -B/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug --check-build-system CMakeFiles/Makefile.cmake 0
>> /usr/bin/cmake.exe -E cmake_progress_start /cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug/CMakeFiles /cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug/CMakeFiles/progress.marks
>> make -f CMakeFiles/Makefile2 all
>> make[2]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>> make -f CMakeFiles/PharoVMCore.dir/build.make CMakeFiles/PharoVMCore.dir/depend
>> make[3]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>> cd /cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug && /usr/bin/cmake.exe -E cmake_depends "Unix Makefiles" /cygdrive/z/oscogvm /cygdrive/z/oscogvm /cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug /cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug /cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug/CMakeFiles/PharoVMCore.dir/DependInfo.cmake --color=
>> make[3]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>> make -f CMakeFiles/PharoVMCore.dir/build.make CMakeFiles/PharoVMCore.dir/build
>> make[3]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>> [ 1%] Building C object CMakeFiles/PharoVMCore.dir/platforms/Cross/vm/sqExternalSemaphores.c.o
>> /usr/bin/x86_64-w64-mingw32-gcc.exe -DBUILD_SQUEAK_STATIC -DBUILD_VM_CORE -DIMMUTABILITY=1 -DNO_ISNAN=1 -DPharoVM=1 -DSQUEAK_BUILTIN_PLUGIN -DUSE_GLOBAL_STRUCT=0 -DUSE_INLINE_MEMORY_ACCESSORS -DVM_NAME=\"Pharo\" -D_GNU_SOURCE -I/cygdrive/z/oscogvm/. -I/cygdrive/z/oscogvm/include -I/cygdrive/z/oscogvm/platforms/Cross/vm -I/cygdrive/z/oscogvm/platforms/Cross/plugins -I/cygdrive/z/oscogvm/spur64src/vm -I/usr/include/SDL2 -I/cygdrive/z/oscogvm/platforms/minheadless/common -I/cygdrive/z/oscogvm/platforms/minheadless/unix -I/cygdrive/z/oscogvm/src/plugins/SqueakFFIPrims -I/cygdrive/z/oscogvm/platforms/unix/plugins/SqueakFFIPrims -I/cygdrive/z/oscogvm/platforms/Cross/plugins/SqueakFFIPrims -I/cygdrive/z/oscogvm/src/plugins/IA32ABI -I/cygdrive/z/oscogvm/platforms/unix/plugins/IA32ABI -I/cygdrive/z/oscogvm/platforms/Cross/plugins/IA32ABI -I/cygdrive/z/oscogvm/src/plugins/FilePlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/FilePlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/FilePlugin -I/cygdrive/z/oscogvm/src/plugins/FileAttributesPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/FileAttributesPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/FileAttributesPlugin -I/cygdrive/z/oscogvm/src/plugins/LargeIntegers -I/cygdrive/z/oscogvm/platforms/unix/plugins/LargeIntegers -I/cygdrive/z/oscogvm/platforms/Cross/plugins/LargeIntegers -I/cygdrive/z/oscogvm/src/plugins/LocalePlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/LocalePlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/LocalePlugin -I/cygdrive/z/oscogvm/src/plugins/MiscPrimitivePlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/MiscPrimitivePlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/MiscPrimitivePlugin -I/cygdrive/z/oscogvm/src/plugins/SecurityPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/SecurityPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/SecurityPlugin -I/cygdrive/z/oscogvm/src/plugins/SocketPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/SocketPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/SocketPlugin -I/cygdrive/z/oscogvm/src/plugins/B2DPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/B2DPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/B2DPlugin -I/cygdrive/z/oscogvm/src/plugins/BitBltPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/BitBltPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/BitBltPlugin -I/cygdrive/z/oscogvm/src/plugins/FloatArrayPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/FloatArrayPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/FloatArrayPlugin -I/cygdrive/z/oscogvm/src/plugins/FloatMathPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/FloatMathPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/FloatMathPlugin -I/cygdrive/z/oscogvm/src/plugins/Matrix2x3Plugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/Matrix2x3Plugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/Matrix2x3Plugin -I/cygdrive/z/oscogvm/src/plugins/SurfacePlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/SurfacePlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/SurfacePlugin -I/cygdrive/z/oscogvm/src/plugins/DropPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/DropPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/DropPlugin -I/cygdrive/z/oscogvm/src/plugins/ZipPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/ZipPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/ZipPlugin -I/cygdrive/z/oscogvm/src/plugins/ADPCMCodecPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/ADPCMCodecPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/ADPCMCodecPlugin -I/cygdrive/z/oscogvm/src/plugins/AsynchFilePlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/AsynchFilePlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/AsynchFilePlugin -I/cygdrive/z/oscogvm/src/plugins/BMPReadWriterPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/BMPReadWriterPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/BMPReadWriterPlugin -I/cygdrive/z/oscogvm/src/plugins/DSAPrims -I/cygdrive/z/oscogvm/platforms/unix/plugins/DSAPrims -I/cygdrive/z/oscogvm/platforms/Cross/plugins/DSAPrims -I/cygdrive/z/oscogvm/src/plugins/FFTPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/FFTPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/FFTPlugin -I/cygdrive/z/oscogvm/src/plugins/FileCopyPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/FileCopyPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/FileCopyPlugin -I/cygdrive/z/oscogvm/src/plugins/JoystickTabletPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/JoystickTabletPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/JoystickTabletPlugin -I/cygdrive/z/oscogvm/src/plugins/MIDIPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/MIDIPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/MIDIPlugin -I/cygdrive/z/oscogvm/src/plugins/SerialPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/SerialPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/SerialPlugin -I/cygdrive/z/oscogvm/src/plugins/SoundCodecPrims -I/cygdrive/z/oscogvm/platforms/unix/plugins/SoundCodecPrims -I/cygdrive/z/oscogvm/platforms/Cross/plugins/SoundCodecPrims -I/cygdrive/z/oscogvm/src/plugins/SoundGenerationPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/SoundGenerationPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/SoundGenerationPlugin -I/cygdrive/z/oscogvm/src/plugins/StarSqueakPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/StarSqueakPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/StarSqueakPlugin -I/cygdrive/z/oscogvm/src/plugins/JPEGReaderPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/JPEGReaderPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/JPEGReaderPlugin -I/cygdrive/z/oscogvm/src/plugins/JPEGReadWriter2Plugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/JPEGReadWriter2Plugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/JPEGReadWriter2Plugin -I/cygdrive/z/oscogvm/src/plugins/RePlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/RePlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/RePlugin -I/cygdrive/z/oscogvm/src/plugins/InternetConfigPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/InternetConfigPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/InternetConfigPlugin -I/cygdrive/z/oscogvm/src/plugins/SqueakSSL -I/cygdrive/z/oscogvm/platforms/unix/plugins/SqueakSSL -I/cygdrive/z/oscogvm/platforms/Cross/plugins/SqueakSSL -I/cygdrive/z/oscogvm/src/plugins/AioPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/AioPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/AioPlugin -I/cygdrive/z/oscogvm/src/plugins/EventsHandlerPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/EventsHandlerPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/EventsHandlerPlugin -I/cygdrive/z/oscogvm/src/plugins/SDL2DisplayPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/SDL2DisplayPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/SDL2DisplayPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/Mpeg3Plugin/libmpeg -I/cygdrive/z/oscogvm/platforms/Cross/plugins/Mpeg3Plugin/libmpeg/audio -I/cygdrive/z/oscogvm/platforms/Cross/plugins/Mpeg3Plugin/libmpeg/video -I/cygdrive/z/oscogvm/src/plugins/Mpeg3Plugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/Mpeg3Plugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/Mpeg3Plugin -I/usr/include/freetype2 -I/cygdrive/z/oscogvm/src/plugins/FT2Plugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/FT2Plugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/FT2Plugin -I/cygdrive/z/oscogvm/src/plugins/VMProfileLinuxSupportPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/VMProfileLinuxSupportPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/VMProfileLinuxSupportPlugin -I/cygdrive/z/oscogvm/src/plugins/UnixOSProcessPlugin -I/cygdrive/z/oscogvm/platforms/unix/plugins/UnixOSProcessPlugin -I/cygdrive/z/oscogvm/platforms/Cross/plugins/UnixOSProcessPlugin -I/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug -pthread -g -DDEBUGVM=1 -o CMakeFiles/PharoVMCore.dir/platforms/Cross/vm/sqExternalSemaphores.c.o -c /cygdrive/z/oscogvm/platforms/Cross/vm/sqExternalSemaphores.c
>> make[3]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>> make[2]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>> make[1]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>>
>> No wonder cmake hides the output by default ;-)
>>
>> Still no information on where the configurations lie, and since they're all computed in a pre-build step one has to essentially decompile the makefiles to get back to the config files that are where the configuration variables are really hiding.
>>
>>
>>
>>> On Nov 29, 2018, at 3:36 PM, Eliot Miranda <eliot.miranda at gmail.com <mailto:eliot.miranda at gmail.com>> wrote:
>>>
>>> and then there's this. Having spotted the apparent error (a case difference for sqPlatformSpecific-Win32.h in platforms/minheadless/common/sqPlatformSpecific.h) I rerun the build and see the following output, essentially unchanged:
>>>
>>> -- Build files have been written to: /cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/release
>>> make -C debug all
>>> make[1]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>>> make[2]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>>> make[3]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>>> Scanning dependencies of target PharoVMCore
>>> make[3]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/phar
>>> o.cog.spur/debug'
>>> make[3]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>>> [ 1%] Building C object CMakeFiles/PharoVMCore.dir/platforms/Cross/vm/sqExternalSemaphores.c.o
>>> In file included from /cygdrive/z/oscogvm/platforms/Cross/vm/sq.h:212:0,
>>> from /cygdrive/z/oscogvm/platforms/Cross/vm/sqExternalSemaphores.c:31:
>>> /cygdrive/z/oscogvm/platforms/minheadless/common/sqPlatformSpecific.h:36:39: fatal error: sqPlatformSpecific-Win32.h: No such file or directory
>>> compilation terminated.
>>> make[3]: *** [CMakeFiles/PharoVMCore.dir/build.make:63: CMakeFiles/PharoVMCore.dir/platforms/Cross/vm/sqExternalSemaphores.c.o] Error 1
>>> make[3]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>>> make[2]: *** [CMakeFiles/Makefile2:216: CMakeFiles/PharoVMCore.dir/all] Error 2
>>> make[2]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>>> make[1]: *** [Makefile:84: all] Error 2
>>> make[1]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'
>>> make: *** [Makefile:2: all] Error 2
>>>
>>> What's missing?
>>> - no mention of a LOG file name to go look for the command line for the compiler which is likely missing an include path to pick up platforms/minheadless/windows/sqPlatformSpecific-Win32.h
>>> - no command line so one can't merely eyeball the output to heck, or run the build with output piped into one's own LOG file
>>>
>>> What doe we see? An opaque build system. The only way to approach this is to wade through the details trying to uncover things *that should be in plain view*. With the Makefiles I have written
>>> - there is no slow configure step (the above make scheme crates 4 identical copies of a config file *on each build*)
>>> - the commandos theat build are output explicitly so one may quickly debug errors in code one is writing
>>>
>>> I'm sorry to complain but this use of cmake is painful and misguided.
>>>
>>> On Wed, Nov 28, 2018 at 7:14 PM Eliot Miranda <eliot.miranda at gmail.com <mailto:eliot.miranda at gmail.com>> wrote:
>>> Hi All,
>>>
>>> I've just attempted to build minheadless on win32 in build.minheadless.cmake. It failed, but it took a long time to do so, while I waited. So I cleaned and repeated to measure just how long I waited. So this time is a best case; all read files are in cache etc. I'm running a Windows VM on a top of the line MacBook Pro and yet it takes 3 minutes and 20 seconds to configure and then start to build and fail because it can't find sqplatfozrmspecifc-win32.h. I have to wait 3 minutes and 20 seconds before I can find out a missing file. This is *wrong*.
>>>
>>> Using make on a build slave is fine, if you insist, but clearly not necessary (our current builds do not use cmake, and even then on ARM build slaves they sometimes timeout). But for development this is madness. We should have a build system which is reactive, which gives feedback too the developer quickly, not after 3 minutes and 20 seconds on state of the art hardware.
>>>
>>> I find it absurd that a Smalltalk community, which well understands the value of incrementally and reactivity, can be satisfied with a VM build system that takes 3 minutes and 20 seconds before it does anything useful. It feels like being back at York University in the early '80's, waiting for the PDP 10. No, that was faster. On reflection, it reminds me of having to post coding sheets to be typed in by entry clerks through the mail while I was at school in the '70's. Back to the future indeed.
>>> _,,,^..^,,,_
>>> best, Eliot
>>>
>>>
>>> --
>>> _,,,^..^,,,_
>>> best, Eliot
>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181130/c05e705f/attachment-0001.html>
More information about the Vm-dev
mailing list