<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Eliot --<div><br></div><div>Cmake might be a step into the right direction, considering low-effort, cross-platform compatibility.</div><div><br></div><div>If you want a single person to be able to maintain all platforms, then a single representation would be nice. Sure, static Makefiles could be just that. Unfortunately, static makefiles often entail too much redundancy and brittle, hard-coded magic. It's very easy to make mistakes.</div><div><br></div><div>If you want specific shepherds for each platform, then we would keep autoconf for Linux because that's what one would use on Linux, right? Anyway...</div><div><br></div><div>Cmake sounds like the better compromise for our situation. Static makefiles do not. Ian already sketched a Cmake config for the SqueakVM before the beginning of Cog. So, we wouldn't even have to start at zero.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 01.10.2021 06:06:11 schrieb Eliot Miranda <eliot.miranda@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif"> <br><br><br>> On Sep 28, 2021, at 7:47 AM, Tobias Pape <das.linux@gmx.de> wrote:<br>> <br>> <br>> Hi<br>> <br>> <br>>>> On 28. Sep 2021, at 16:39, Eliot Miranda <eliot.miranda@gmail.com> wrote:<br>>>> <br>>>> <br>>>> <br>>>>> On Sep 28, 2021, at 5:39 AM, Marcel Taeumel <marcel.taeumel@hpi.de> wrote:<br>>>> <br>>>> <br>>>> Hi Bruce --<br>>>> <br>>>>> What debian package is it trying to find the cflags for?<br>>>> <br>>>> glib, pango, cairo, ... something like this:<br>>>> <br>>>> UNICODE_PLUGIN_CFLAGS = -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16<br>>>> UNICODE_PLUGIN_LIBS = -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lcairo<br>>>> <br>>> <br>>> We will have to elaborate the makefiles to remove the processor specificity.  An if-then-elif-then Chan is needed fir the processor specificity.  arm64 and x86_64 are only two of several possibilities here.<br>> <br>> What you see there was provided by pkg-config.<br>> it is linux-specifc and necessary due to glib (not to be confused with glibc)<br>> <br>> these path are not in the repo. <br>> <br>>> <br>>> I am building the Virtend vm on Apple silicon and x86_64 and have to do similarly.<br>>> <br>>> But more concerning is the glibc version.  The entire vm must use the same glibc version and so if we want to be able to specify it we need a variable name and that needs to be used across the entire vm build.<br>>> <br>>> Again let me suggest that using static makefiles is far easier and faster to implement and debug this kind of flexibility rather than the autoconf nightmare we endure now.<br>> <br>> They confuse the hell out of me.<br><br>Perhaps.  You can learn.<br><br>> And break profoundly once any of the involved 3drpartys (linux,distro,windors,apple) changes any path…<br><br>That’s simply not so.  The information about the various oaths has to be somewhere.  It isn’t magic.  The information is either in autoconf, necessitating a rebuild, and dealing with the two phase build, or in a makefiles.  Putting variants in a makefiles has the advantage that one can see the variants in context. For example, a makefile in platforms/unix/plugins/UnicodePlugin is a much more natural place to put and find variants in building Unicode than in magic inside platforms/unix/conf.<br><br>> <br>> -t<br>> <br>>> <br>>>> Best,<br>>>> Marcel<br>>>>> Am 28.09.2021 13:18:22 schrieb Bruce O'Neel <bruce.oneel@pckswarms.ch>:<br>>>>> <br>>>>> Hi, <br>>>>> <br>>>>> Nope, you are right, I am one commit behind. <br>>>>> <br>>>>> I'll check that out and build.  Thanks! <br>>>>> <br>>>>> bruce <br>>>>> <br>>>>> On 2021-09-28T13:06:40.000+02:00, Tobias Pape <br>>>>> wrote: <br>>>>> <br>>>>> Hi Bruce <br>>>>> <br>>>>>  On 28. Sep 2021, at 12:44, Bruce O'Neel  wrote: <br>>>>> <br>>>>> HI, <br>>>>> <br>>>>> On my arm64 system the unicode plugin is disabled. <br>>>>> <br>>>>> But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted. <br>>>>> <br>>>>> What debian package is it trying to find the cflags for? <br>>>>> <br>>>>> It should be, i missed the reconfigure, but commited that… <br>>>>> Can you check you're on the latest checkout? <br>>>>> -t <br>>>>> <br>>>>> <br>>>>> Thanks. <br>>>>> <br>>>>> bruce <br>>>>> <br>>>>> <br>>>>> Hi,<br>>>>> <br>>>>> Nope, you are right, I am one commit behind.<br>>>>> <br>>>>> I'll check that out and build.  Thanks!<br>>>>> <br>>>>> bruce<br>>>>> <br>>>>> On 2021-09-28T13:06:40.000+02:00, Tobias Pape <das.linux@gmx.de> wrote:<br>>>>> Hi Bruce<br>>>>> <br>>>>> <br>>>>> On 28. Sep 2021, at 12:44, Bruce O'Neel <bruce.oneel@pckswarms.ch> wrote:<br>>>>> <br>>>>> HI,<br>>>>> <br>>>>> On my arm64 system the unicode plugin is disabled.<br>>>>> <br>>>>> But on my two Raspberry PI Arm 32 systems, one old and one new, the unicode plugin tries to build but fails because @UNICODE_PLUGIN_CFLAGS@ is not substituted.<br>>>>> <br>>>>> What debian package is it trying to find the cflags for?<br>>>>> <br>>>>> It should be, i missed the reconfigure, but commited that…<br>>>>> Can you check you're on the latest checkout?<br>>>>> -t<br>>>>> <br>>>>> <br>>>>> Thanks.<br>>>>> <br>>>>> bruce<br>> <br>> <br></bruce.oneel@pckswarms.ch></das.linux@gmx.de></bruce.oneel@pckswarms.ch></marcel.taeumel@hpi.de></eliot.miranda@gmail.com></das.linux@gmx.de></div></blockquote></div>