libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Organization of ltmain.in into sub-files


From: Alex Ameen
Subject: Organization of ltmain.in into sub-files
Date: Sun, 17 Oct 2021 21:13:08 -0500

Howdy,

I spent a few hours today seeing how reasonable it would be to split the ~9,000 `ltmain.in' script into a collection of smaller `m4sugar' files to make it a bit easier to read/maintain. This began as a way for me to get my feet wet with modifying `ltmain.in', but I was pleasantly surprised by how well it's been working out so far.

Notably I am strictly using `m4sugar', not `m4sh' which is more of a challenge ( trying to port diversions and wrapper scripts is a large effort ); but I've followed the same general patterns that might make alignment easier in the future.

I've essentially moved one function at a time into various categories of sub-files, some associated with each mode, IO for printing messages, file/path handling. Each function is placed in a "PREPARE" block with an associated `m4_defun_init' which references it. This means these functions are still available exactly as they were before as regular shell functions, but the M4 wrappers now exist as alternates that could be aligned quite easily with the rest of `autom4te' usage.

I've found that not only are things a bit easier to navigate now, but that the use of `m4_require' blocks has made ordering the script's contents much easier.

I integrated the generation of `ltmain.in' from `ltmain.in.m4' into the appropriate bootstrap and build files such that `ltmain.in' is packaged as it was before - so `ltmain.in.sh' is effectively only relevant for maintainers or people making extensions.

Test suite matches an unmodified branch as well which is good.


I thought I had seen in some TODO notes that other maintainers had been working on reorganizing `ltmain.in', so I wanted to poke my head in and see if there was an existing branch doing this sort of works, or if this was something that anyone thinks would be useful as a project branch? Right now I just have it living in a fork of the GitHub mirror. I imagined uploading patches would be pretty difficult to read since there's so many files created and snippets moved, but if anyone prefers to check things out that way let me know.

Thanks for reading!

--
Alex Ameen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]