[squid-dev] [RFC] The situation with helpers/

[Alex Rousskov]

On 01/13/2016 01:50 PM, Amos Jeffries wrote:

> Small side-track (sorry):
> 
> My experiments in fixing that makefile dependencies situation have
> resulted in a few conclusions. Though nowhere near complete the
> lp:~yadi/squid/makefile-deps branch has the latest version of what I
> think it should look like.
> 
> * First stage, bar none is to simply stop adding new foo_DEPENDENCIES
> lines to any .am file. We can/should/need all do that right now.
> 
> * Second stage is to remove existing *_DEPENDENCIES where possible. I
> have found that needs to be done with care, bulk erasing or moving the
> entris to LDADD lists is not always correct. The branch did it and a few
> test binaries had inconsistent builds until their SOURCES were
> corrected. Still not sure I got them all yet.
> 
> * Third stage is to reduce the SOURCES and LDADD lists to the actual
> minimal set needed (maybe increase to full set needed). Stubs helps
> there a lot, but a) some new ones are needed, b) some existing are
> incorrect, and c) more/better use of the ones we have improves automake
> results.
> 
> * Fourth stage I am experimenting with in the branch now is
> non-recursive unit tests. By using src/*/UnitTest.am files we can have
> the tests defined in their respective sudir, but actually built and run
> non-recursive by the src/Makefile.


FWIW, if I were to solve this problem, I would try to write a script
that generates 95-99% of the Makefile.am rules based on:

* dependencies auto-discovered by scanning #include statements in
sources (probably using gcc or clang capabilities) and

* limited Squid-specific (or configurable) knowledge of external and
unusual dependencies.

IMHO, the problem is not solvable by automation in a general case, but
is solvable with [and should be solved by] automation in the context of
Squid.


> automake itself is migrating upstream to a model where it assumes
> recursive Makefiles and deals better with those sometimes than
> non-recursive. eg. the whole subdirs feature in 1.12+.

Can you share any references to support the above statement about
automake development direction? AFAIK, the subdir-objects option/fix was
added to, in part, better support *non-recursive* Makefiles so it sounds
like a counter-example to me, but perhaps you meant something else by
the "subdirs feature".


The difference between recursive and non-recursive Makefiles is of
secondary importance though: A Makefile.am-generating script can
probably handle both styles although a non-recursive Makefile is
probably easier to generate because the make solves the build-order
problem for us.


> IMO the recursive design is better. We have to take care where we put
> things in either case. But with recursive we can reduce the focus to
> only the dirs, not every individual file in the sources.

I do not see any significant difference in "focus" between (in
pseudo-Makefile.am):

  # non-recursive
  FOO_SOURCES = foo.cc foo.h \
                $(DIR1_SOURCES) $(DIR2_SOURCES)

and

  # recursive
  FOO_SOURCES = foo.cc foo.h
  FOO_LDADD = dir1/libdir1.la dir2/libdir2.la


but, again, I suspect the best style should be determined by automated
Makefile.am-generation needs and not discussion about the human focus.
Once the problem is solved with automation, the above pretty much becomes:

  FOO_SOURCE = foo.cc

as far as humans are concerned.


HTH,

Alex.