Some autoconf cleanups

[Ruben Kerkhof]

On Tue, Mar 14, 2017 at 2:08 PM, Ondrej Zajicek <santiago at crfreenet.org> 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 <santiago at crfreenet.org> 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: santiago at crfreenet.org)
> 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