#gnu autotools

Wayland adiciona suporte ao sistema Meson Build e X.Org Server 1.20.7 lançado

O Wayland em Weston usa o sistema de compilação Meson há cerca de um ano. Porém, apenas esta semana o próprio Wayland teve finalmente o suporte a Meson introduzido. O Wayland adicionou o suporte ao sistema de compilação Meson pelos mesmos motivos que a maioria dos projetos: tempos de compilação mais rápidos, mais limpos que o GNU Autotoolse tende a funcionar melhor em outras plataformas,…

It’s been four years since I last wrote a post on Unit Testris. I have commits for the next year after that but it’s been 3 years since I touched the project. Recently I thought I might try incrementally porting the program to Rust, and to start I had to get the old code to build again.

It turned out that simply reinstalling all the libraries and dev packages wasn’t enough - changes in the Gnu Compiler Collection broke my project. There were two issues of this kind: First, g++ is now enforcing constexpr rules that forbid certain kinds of casts in a constexpr. Specifically, I was reinterpret casting numbers to a pointer so I could pass it as an argument to an OpenGL function which internally reinterpret casts that pointer to a number. If you aren’t familiar with OpenGL and that sounds ridiculous to you, be assured that there is a reason OpenGL does that, and that reason is ridiculous. So now that number is const instead of constexpr in recognition of rules set out in the c++ standard, which is fair. But the g++ error message not having the word “constexpr” in it is not fair, I got the idea that some option was telling the compiler not to accept any cast from integer to pointer..

The second issue is that if you use the C++ standard library threads, the GNU/Linux linker will now fail unless you explicitly link pthreads with -lpthreads. The autotools macro to detect pthreads tests C compliation, because pthreads are a C library so of course it does that. But it means that the result of that macro is not necessarily correct for a C++ project and indeed that macro is useless to me, so I just manually put -pthreads in the Makefile.am because I have reached my limit, I can’t care about the portability of my toy self-teaching project that much.

I've just fixed a bunch of problems with how I had the GNU Autotools set up which were breaking compilation.

Basically, it turns out that $LDFLAGS is not the variable you want to put things like -lfltk to get them passed to the linker - for that you use $LDADD. The difference is which side of filename.o the variable is placed, which is something the linker cares about. Mine didn't used to care, or the autotools used to fix it for me. When your build environment silently ceases silently fixing a mistake you didn't know you were making, you get baffled. Thanks to linuxquestions.org for pointing out the ordering issue, after which Google® led me to $LDADD.

Meanwhile, I got a newer version of g++, and AX_CXX_COMPILE_STDCXX_0X reports that I now have access to c++11 (formerly known as c++0x)  features, provided that I pass one of two compiler options to g++. This macro is also helpfully defining the symbol which tells the preprocessor not to replace nullptr with 0. Much to my surprise, it did not helpfully insert the option which is required for c++11 support into CXXFLAGS, and so introduced a compilation failure.

I thus set out to write myself an m4 macro to handle the possible necessity of such an option. This is hard to do when you have no experience and the Internet is surprisingly reluctant to produce autotools tutorials that amount to more than presenting extremely basic configure.ac and Makefile.am files and telling you that these files do stuff for you. The generally accepted best source appears to be slides for a lecture. So far as I can tell, these are slides from a fine lecture. However, they don't stand up all that well on their own.