[Vm-dev] The insanity of using make for development builds

Ronie Salgado roniesalg at gmail.com
Fri Nov 30 23:46:09 UTC 2018


 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 ). 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 (<phil at highoctane.be>)
escribió:

>
>
>
> On Fri, Nov 30, 2018 at 8:55 AM Jakob Reschke <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/ 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>:
>>
>>>
>>>
>>>
>>> Le ven. 30 nov. 2018 à 07:46, Norbert Hartl <norbert at hartl.name> a
>>> écrit :
>>>
>>>>
>>>>
>>>>
>>>> Am 30.11.2018 um 01:38 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>>>
>>>>
>>>>
>>>> On Thu, Nov 29, 2018 at 4:32 PM Eliot Miranda <eliot.miranda at gmail.com>
>>>> wrote:
>>>>
>>>>> thanks Todd,
>>>>> On Thu, Nov 29, 2018 at 3:59 PM Todd Blanchard <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
>>>>>>
>>>>>
>>>>> 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>
>>>>>> 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> 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/174b915c/attachment-0001.html>


More information about the Vm-dev mailing list