Hi
On 1. Oct 2021, at 06:05, Eliot Miranda eliot.miranda@gmail.com wrote:
[…]
They confuse the hell out of me.
Perhaps. You can learn.
Admittedly, I have not yet spend as many years looking at them. The experience with Self's static-makefile-based build-system was enough however to see for me that, unless your environment gives you enough help (Eg, OpenBSDs default makefile includes), you'll have a hard time collecting all necessary information in a tractable way.
And break profoundly once any of the involved 3drpartys (linux,distro,windors,apple) changes any path…
That’s simply not so. The information about the various oaths has to be somewhere.
Have you seen the demise of apple's developer documentation? It's a clusterf$$#. Other people have and can spend way more time on figuring all that stuff out. And they do. And they create things like autoconf, cmake, gyp, scons, etc.
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.
My change to platforms/unix/conf for UnicodePlugin is solely due to the way Ian wrote the plugin-support macros, as it did not foresee the multitude of ways that some libs need their Compiler Parameters be set up.
Look at pangocairo. Since it depends on glib, you won't get around pkg-config. Why? because look at the cflags necessary to build against pangocairo on my Ubuntu 20.04:
% pkg-config --cflags pangocairo -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -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/uuid -I/usr/include/freetype2 -I/usr/include/libpng16
These paths all will be different for: distri (different even debian/ubuntu), abi, platform, whatdoiknow.
Thus, the simple "find library to link against for plugin" macro of Ians does not work. Incidentally, when he ditched autoconf for cmake, these things got quite a bit easier...
So, hardcoding those in a static makefile is not possible. One _could_ use pkg-config in a makefile, but then we are in dynamicland again. And when we are in dynamicland already, I really don't see value in scattering this information all over 214 mvm files, and 240 makefiles.
===========
What I do when I touch autoconf, is to try to make broken things work in a way that fits the system as is.
I am not to argue anything here. I'll try to fit in.
-tobias
-t
Best, Marcel
Am 28.09.2021 13:18:22 schrieb Bruce O'Neel bruce.oneel@pckswarms.ch:
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape wrote:
Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel wrote:
HI,
On my arm64 system the unicode plugin is disabled.
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.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce
Hi,
Nope, you are right, I am one commit behind.
I'll check that out and build. Thanks!
bruce
On 2021-09-28T13:06:40.000+02:00, Tobias Pape Das.Linux@gmx.de wrote: Hi Bruce
On 28. Sep 2021, at 12:44, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
HI,
On my arm64 system the unicode plugin is disabled.
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.
What debian package is it trying to find the cflags for?
It should be, i missed the reconfigure, but commited that… Can you check you're on the latest checkout? -t
Thanks.
bruce