On Mon, Nov 17, 2025 at 12:24:01AM +0100, Patrice Dumas wrote: > > Broadly speaking: I don't have a good understanding of all of this. > > You have some, as you actually reimplemented what ExtUtils::Embed does, with > more granularity with tta/m4/txi_perl_conf.m4. And you can do relevant > proposals...
I'm concerned that the build system under tta/ is quite convoluted. There are a lot of variables. Each built object (library or program) has its own flags. The build system may not have always been particularly well-organised but it has grown with the increase in C/XS code (which is quite to be expected). > No, there are two settings, each with a specific way to do configure > checks. Maybe it is not well explained, but it is relatively simple. > There are only two "perl C" configure checks, one in > tta/m4/txi_libperl_link.m4 > and the other in tta/m4/txi_embedded_perl.m4, all the other checks are > "pure C" autoconf and gnulib typical checks. > > Then the _CPPFLAGS, _LIBADD, _LDFLAGS and _CFLAGS need to be carefully > specified for the diverse libraries, depending on whether they contain > "perl C" or "pure C" code, this part is not particularly complex, there > are two cases, and two different sets of flags but maybe more prone to > errors. What is more a pain is that the libraries interdependencies > need to be correct, and the LIBINTL and similar need to be specified > correctly. One example: every library built in tta/perl/XSTexinfo/Makefile.am has *_CFLAGS specified separately (all 12 of them). Could we not set it once in AM_CFLAGS for the entire Makefile.am? (Same for *_LDFLAGS.) There are *_LIBADD flags for most of these libraries, but they are all different, and there doesn't seem to be a way in Automake to set LIBADD once for all libraries. Nearly all of these have $(platform_PERL_LIBADD), and it would be easy to miss this out somewhere by mistake (I don't have an answer for this). (I guess the library interdependencies are like C header files which we have to manually maintain inclusions of.) > > Then some of the libraries are linked together with _LIBADD > > variables, even though they've potentially been compiled differently > > and may not necesessarily be compatible. > > Not compatible in which sense? In term of binary interfaces? Yes, exactly. It seems quite possible that there are settings of CFLAGS that could lead to binary incompatibility. There could be definitions that change the definition of data types in header files, for example. > > There is a "platform_PERL_LIBADD" variable used throughout tta/C/Makefile.am > > which does not appear to be set anywhere, as far as I can tell. > > It is set in tta/m4/txi_perl_conf.m4, on platforms that need to be > linked with no-undefined, it adds that link flags to link against > libperl. And it is mainly derived from the code you did... I've added a comment to say it is set in txi_PERL_CONF as otherwise it's hard to find. > > It was simpler when the XS code was more limited and we made much less > > use of gnulib. In that case all of the C code in the XS subdirectory > > was compiled with the compiler and flags for XS extensions. > > It was not so simple, there were kludges since a long time that, in my > opinion, were as bad as the current state of separation of code, to > undefine symbols. Currently the separation is a bit of a pain because > it adds constraints on which function should go to which file, but > overall it seems much cleaner to me. And I also remember that a > platform that failed in a strange way was fixed as a side-effect of > separating "pure C" with gnulib and "perl C" for compilation. Yes, it was good these errors were fixed when you separated the code. Maybe the incompatibilities are limited to clashing header file definitions and using Perl compiler and/or linker flags with source files compiled with Gnulib wouldn't be a problem. > > As I remember, gnulib definitions and Perl definitions (from Perl > > header files) would sometimes clash, leading you to go to the effort > > of separating the two. > > -- > Pat
