On Wednesday, January 31, 2018 at 2:46:10 PM UTC, Jeroen Demeyer wrote: > > On 2018-01-31 14:37, Erik Bray wrote: > > All that's changed is how they're presented. > > But that is a very important change! It's like "all I changed is > replacing your car by instructions on how to build a car". > > > I'm replacing this: > > I don't see it that way. In my mind you are replacing readable rules like > > > $(INST)/zeromq-4.0.5.p2: > +$(AM_V_at)sage-logger -p '$(SAGE_SPKG) zeromq-4.0.5.p2' > '$(SAGE_LOGS)/zeromq-4.0.5.p2.log' > > zeromq: $(INST)/zeromq-4.0.5.p2 > > zeromq-clean: > rm -f $(INST)/zeromq-4.0.5.p2 > > > > with this: > > > > define NORMAL_PACKAGE_templ > > $$(INST)/$(1)-$$(vers_$(1)): $$(foreach > dep,$$(deps_$(1)),$$(inst_$$(dep))) > > +$(AM_V_at)sage-logger -p '$(SAGE_SPKG) $(1)-$$(vers_$(1))' > > '$(SAGE_LOGS)/$(1)-$$(vers_$(1)).log' > > > > $(1): $$(INST)/$(1)-$$(vers_$(1)) > > > > $(1)-clean: > > rm -rf $$(INST)/$(1)-$$(vers_$(1)) > > endef > > > > $(foreach pkgname,$(NORMAL_PACKAGES),\ > > $(eval $(call NORMAL_PACKAGE_templ,$(pkgname)))) > > > > That's fair. I understand--you don't like that you don't immediately > > see the make rules expanded. > > That is *exactly* my point indeed. >
It is a fact of life that macros are less readable than their expansions. We have to live with this if we do not want to drown in hundreds of essentially the same rules. I can say that automake has a much nicer way to do this, although less flexible. What is the reason we do not use it? > > > What > > you're complaining about amounts to leaving C macros unexpanded--you > > want to see the "real" C code with no macros. > > Yes because sometimes you really need to look at the C code without the > macros. As with "configure" output, I do that sometimes. > > > Anyways, you can *always* see the fully expanded rules by running > > `make -p` though this tends to be very wordy and it can be hard to > > find exactly what you're looking for > > Thanks for that tip. It's essentially what I was looking for. The only > annoyance is that the build/make/install front makes it non-trivial to > actually run "make -p" on that Makefile. > > > What principle, exactly, are you complaining against? > > I think it should be clear by now that I'm complaining against the fact > that the actual Makefile rules are hidden under an obscure template. > > > Let me step back a little bit. Forget about the makefile itself for a > sec. > > > > Part of the point of this is that we aren't really using autoconf as > > it's intended in the first place. The configure script itself is not > > really supposed to write files at all, except for a few files specific > > to the autoconf system. The purpose is the configure script is to > > *collect information* about the system and the build context. That's > > it. It's for information gathering. And the way I've tweaked it is > > exactly that--it scans the SPKGs and gathers information about them > > into some datastructures that can be used by make, from which I tried > > to reduce as much redundancy as possible. > > > > When the configure script completes its information gathering it > > writes one file, config.status, into which it also writes whatever > > information gathered by configure we most care about (as specified by > > AC_SUBST(...)). The AC_SUBST variables are then replaced into > > templates by config.status--it's the script that's actually supposed > > to be writing files. > > > > Now, of course, you'll object--configure is just a shell script, and > > we can do absolutely anything we want in it. Sure. I admit I don't > > have a great technical argument against this. I think that it's a bit > > prettier. The AC_SUBST variables I gather, I think, do a fair bit to > > eliminate redundancy, and the use of (autoconf) templates is a bit > > prettier. I think my configure.ac is a lot simpler and easier to > > understand (and even moreso in one of my other branches of this where > > I've moved all the package scraping into a AC_DEFUN macro in a > > separate file). > > > > I'll also mention, again, that this has made running ./configure > > *much* faster, and the impact it has on running make is minimal. > > I agree with most of what you write here. It's essentially the premise > of ticket 21524. But that doesn't mean that I have to agree with the > approach taken. For example, it might be possible to improve the shell > script inside ./configure.ac to write the rules. Or, we could even use > some other language like Python to do that. > > > At the end of the day, I just feel that if we're going to use these > > tools at all it actually makes sense to use them closer to how they > > were intended. > > I don't think that "make" is meant to be (ab)used like that :-) > No, why? Nontrivial projects have very complicated generated rules in their makefiles. (Look at a typical project that uses automake...) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
