On Tue, Mar 14, 2017 at 2:08 PM, Ondrej Zajicek <[email protected]> wrote: > On Tue, Mar 07, 2017 at 03:20:09PM +0100, Ruben Kerkhof wrote: >> On Tue, Mar 7, 2017 at 12:17 AM, Ondrej Zajicek <[email protected]> >> wrote: >> > On Sat, Mar 04, 2017 at 06:13:16PM +0100, Ruben Kerkhof wrote: >> > Thanks for the cleanup patches, our configure script is old and not much >> > kept up-to-date. I have some questions w.r.t. your patches: >> >> Thanks for looking at my patches. > > Hi > > Accepted and merged, with the exception of patch 07 (rename aclocal.m4 to > m4/bird.m4).
Thanks a lot. > >> I have some follow up patches with more cleanups, but this series is already >> large >> enough as it is. > > I would be glad to see them. Ok, I'll have something ready in the next few days. > > >> >> rename aclocal.m4 => m4/bird.m4 (100%) >> > >> > Is this necessary? I have an aversion to boilerplate directories >> > containing just one file. >> >> It's not strictly necessary since bird doesn't use automake, but m4/ >> is somewhat of a canonical location. >> I have plans to split this file up in later patches, and to see which >> ones of these macros are still needed and possibly redo them >> differently, in configure.ac itself. > > I would prefer to keep self-contained macros in aclocal.m4, while keeping > configure.ac simple. Perhaps even transfer some non-trivial code from > configure.ac (e.g., ncurses finding or sa_len check) to a separate macros > in aclocal.m4. Sounds good. > > But i am OK with removing unnecessary and redoing macros differently in > aclocal.m4 (e.g., integer length testing macros are most likely obsolete > and could be replaced by C99 types). Yes, I was thinking about that. Do you object to switching the code base to just use the fixed width integer types from <stdint.h>? It will be a large change, but mostly mechanical. > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: [email protected]) > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > "To err is human -- to blame it on a computer is even more so." Kind regards, Ruben Kerkhof
