Re: Portability report: ninja

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Portability report: ninja
Дата
Msg-id 20211102042123.bk2pbfij7uwju2c4@alap3.anarazel.de
обсуждение исходный текст
Ответ на Portability report: ninja  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Portability report: ninja  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2021-11-01 15:25:08 -0400, Tom Lane wrote:
> Meson depends on ninja, so it behooves us to look into portability
> of ninja if we're considering migrating to meson as the build system.
> I tried it out quickly on some ancient platforms, and here's what
> I found.

Thanks, that's helpful!


> 1. The documentation is kinda sucky, eg it fails to explain how
> to run ninja's own regression tests.  I ended up with this
> reverse-engineered recipe:
> 
> git clone git://github.com/ninja-build/ninja.git
> cd ninja
> git checkout release
> ./configure.py --bootstrap
> ./ninja ninja_test
> ./ninja_test
> sudo cp ninja /usr/local/bin          # or location of choice
> 
> We'll probably have to include that in our own documentation.

Or perhaps a helper script? I was wondering whether we'd eventually want a
wrapper ./configure / makefile. Perhaps not worth it though - there's enough
projects using meson and ninja that it might add more confusion than being
helpful.


> There is also a process for bootstrapping using cmake, but that doesn't seem
> like a more attractive dependency for old platforms.

Yea. Especially given that meson itself needs python anyway.


> Fortunately for my
> purposes here, it seems to work with fairly old Python --- I built
> successfully with python 2.6.2, though not with 2.4.1.

meson will need a newer python though...


> 4. It built and passed self-test on macOS Leopard (10.5.8), which is
> pretty old ... but not old enough for prairiedog, which is stuck on
> 10.4.x.  There, the build fails miserably for lack of <spawn.h>.
> It looks like that was added to POSIX in 2001, so one could have
> wished for it in a 2005-vintage OS; but nope, Apple took another
> couple of years to get around to that.  I'm not even going to bother
> trying on gaur's pre-turn-of-the-century OS.

> 5. It built and passed self-test on Solaris 11, but failed self-test
> on Solaris 10.

I think we can live with those...


> 6. While configure.py thinks it knows what to do on AIX, it fails
> on AIX 7.1 and 7.2:
> 
> Traceback (most recent call last):
>   File "./configure.py", line 544, in <module>
>     if platform.is_aix() and not platform.is_os400_pase():
>   File "./configure.py", line 103, in is_os400_pase
>     return self._platform == 'os400' or os.uname().sysname.startswith('OS400')
> AttributeError: 'tuple' object has no attribute 'sysname'
> 
> Possibly the ninja guys would take a patch for that (or maybe
> this is a you-need-python-3 case?).  I do see /usr/include/spawn.h
> on that platform, so there's room to hope it'd work.

That does seem like it'd be a issue. Briefly trawling the ninja git log it
does look like there's regular-ish maintenance stuff for AIX, so I'd hope we
could get it fixed. I do suspect it's just a python3 issue, as Thomas noted.


> Based on these results, I doubt that ninja will give us trouble on any
> platform that isn't old enough to get its drivers license.

Agreed.

There's also alternative compatible ninja implementation in C99 ([1]). But I
think it's minimum requirements aren't actually lower than ninja's (it says it
requires posix 2008).

Greetings,

Andres Freund


[1] https://github.com/michaelforney/samurai



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Nancarrow
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: archive modules