Re: Organization of ltmain.in into sub-files

[Alex Ameen]

Gotcha I can contact GNU and handle any merges that are needed based on
submitted patches. The bulk of the "effort" was developing a good pattern
and forcing the build and support scripts to treat `ltmain.in' as a built
target, so honestly merging isn't a major hassle.

Thank you for pointing me in the right direction.

On Mon, Oct 18, 2021, 10:38 AM Bob Friesenhahn 
wrote:

> On Mon, 18 Oct 2021, Alex Ameen wrote:
>
> > This sounds great to me, I'd love to lend a hand.
> >
> > I had filled out the form a few weeks ago when I sent in patch for
> > `/usr/bin/file' references, so that might still be sitting in the queue
> for
> > review. If not, let me know and I can file a new request.
>
> The problem is that there are no libtool maintainers to service your
> requests. :-(
>
> This means that you would need to contact the GNU organization to
> express your interest in becomming a libtool maintainer.
>
> There are many pending bug reports with patches to be integrated. Your
> own work may collide with these patches so they can not be easily
> applied.
>
> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
> Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
>

Re: Organization of ltmain.in into sub-files

[Bob Friesenhahn]

On Mon, 18 Oct 2021, Alex Ameen wrote:


This sounds great to me, I'd love to lend a hand.

I had filled out the form a few weeks ago when I sent in patch for 
`/usr/bin/file' references, so that might still be sitting in the queue for 
review. If not, let me know and I can file a new request.


The problem is that there are no libtool maintainers to service your 
requests. :-(


This means that you would need to contact the GNU organization to 
express your interest in becomming a libtool maintainer.


There are many pending bug reports with patches to be integrated. Your 
own work may collide with these patches so they can not be easily 
applied.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Organization of ltmain.in into sub-files

[Alex Ameen]

This sounds great to me, I'd love to lend a hand.

I had filled out the form a few weeks ago when I sent in patch for 
`/usr/bin/file' references, so that might still be sitting in the queue 
for review. If not, let me know and I can file a new request.


Thank you,

-Alex


On 10/18/21 8:15 AM, Bob Friesenhahn wrote:

On Sun, 17 Oct 2021, Alex Ameen wrote:


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


Your work sounds like an excellent idea.  The major problem for the 
libtool project right now is that (as far as I am aware) there have 
not been active maintainers for years.  It seems like you have the 
skills required for this task.  Becoming an official libtool 
maintainer would help move the project forward and make it easier to 
integrate your own ideas.


Bob

Re: Organization of ltmain.in into sub-files

[Bob Friesenhahn]

On Sun, 17 Oct 2021, Alex Ameen wrote:


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


Your work sounds like an excellent idea.  The major problem for the 
libtool project right now is that (as far as I am aware) there have 
not been active maintainers for years.  It seems like you have the 
skills required for this task.  Becoming an official libtool 
maintainer would help move the project forward and make it easier to 
integrate your own ideas.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Organization of ltmain.in into sub-files

[Alex Ameen]

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