On 11/8/24 4:15 PM, Mike Jonkmans wrote:
I could use a GNUMakefile to get around some of the issues. A fix would be nice.
It wasn't a difficult fix.
2) The use of recursive make, makes it harder to do dependencies right;It's the best way to build using optional components and subdirectories.I have my doubts here. There are potential problems with dependencies and parallel makes wrt linking.
Well, sure. There are always potential problems. But we have to have a real build problem on a real system that's due to parallel make and dependencies, so we know whether or not we've fixed anything.
3) The various Makefiles disagree on 'clean: mostlyclean' versus 'mostlyclean: clean';Is this substantive or just cosmetic?It's a minor cognitive burden, mostly cosmetic.
I can swap those around as I modify the individual makefiles; it's not a big deal.
4) .PHONY is not used for the sub-makes *clean rules;You mean in the subdirectory makefiles?Yes. Though I was focussing on the clean rules. Only two Makefiles have (incomplete) .PHONY rules: # find . -name Makefile | xargs grep PHONY ./lib/malloc/Makefile:.PHONY: malloc stubmalloc ./Makefile:.PHONY: basic-clean clean maintainer-clean distclean mostlyclean maybe-clean One can argue about the substantive versus cosmetic aspect of .PHONY. As it is highly unlikely to accidently create a file named after a target. But they don't hurt - and FWIW may save a stat or two.
Sure, I can add those as well.
5) git (status), .gitignore and make are disconnected;What does this mean? There are a couple of files that I need to add to .gitignore; is this something else?I suggest per directory .gitignore files, that contain:
This isn't really a problem description.
6) There is redundancy/duplication in the actions of various rules;OK.6) Same for the definitions of variables.Examples?There is duplication in the top Makefile on the various lib sources. One might dedup that by creating e.g. lib/glob/Makefile.ext and include that on the toplevel (the lib's Makefile should then use GLOB_SOURCES).
I don't really consider that a problem.
lib/glob/Makefile:
Seems that gmisc.c is missing from CSOURCES
CSOURCES might then be derived from OBJECTS.
The source files don't change often enough to make that work worth it.
The top Makefile defines GLOB_SOURCES, different from those CSOURCES. Oh, i see, #include "glob_loop.c" etc. :(
This is a fairly common idiom for building single-byte and multibyte versions of functions from the same source without duplicating too much code. glibc and gnulib both use it.
Those *_loop.c files are not included in CSOURCES nor in HSOURCES.
OK.
Could be a problem for the what-tar target (via THINGS_TO_TAR).
Those targets aren't used; I inherited them from the original glob library. Bash distributions are built a different way.
(One could argue, whether the devel branch is a distribution.)It's not. It's a snapshot of ongoing work.As such, it has the purpose of: - bringing in early fixes/patches; - communicating future changes, eliciting comments.In many cases, yes. In some cases, I solicit discussion, usually here.So the devel branch should be easy to work with for outsiders.How would the standard make targets make it easier to work with (besides fixing a couple of previously-discussed issues)? What are we doing here beyond `configure; make' and testing out various behaviors?Making people not chase red herrings. I mean that in the output of 'make mostlylean', seeing 'clean' called, makes me want to look at what is wrong.
You're assuming something is wrong based on a set of assumptions about how things `should be', not whether anything is actually misbehaving.
(From 'info (make)Standard Targets')
All GNU programs should have the following targets in their Makefiles:
all install install-html install-dvi install-pdf install-ps
install-strip uninstall
clean distclean mostlyclean maintainer-clean
TAGS info dvi html pdf ps dist check installcheck installdirs
The wording has 'should have'. But I think that if you have any of these
targets, they should be doing the expected.
What is `the expected'? The only one we're really missing here is `installcheck', and few programs seem to have or use it (bash doesn't install anything but the man pages and info files).
Indeed, building ouside of the source directories will not encounter the .gitignore problems. Vaguely rembering some problems with building outside the source. I shall give that another try.
I rarely build in the source tree.
- 'make mostlyclean' removes doc/bashref.* and doc/Makefile.It shouldn't remove the Makefile, and you can make it again, but I can't reproduce it removing the bashref.* files.On devel: make distclean git restore . ./configure make mostlyclean git status Shows several lines of 'deleted: doc/bashref.*'
Those are the files resulting from texinfo creating the dvi files from the texinfo source. They are not part of the bash distribution. We talked about them earlier.
Then:
make distclean
Shows several extra deleted items 'lib/readline/doc/*'
These are files that are included for convenience but are not in the
bash distributions.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
