On Wed, Jan 31, 2018 at 5:15 PM, William Stein <wst...@gmail.com> wrote: > On Wed, Jan 31, 2018 at 6:46 AM, Jeroen Demeyer <j.deme...@ugent.be> 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)))) >> > > If the makefile contained *both* of the above (in some order), what > would happen? Is it an error, or would make prefer one over the > other?
It's an error if you have two rules for the same target in a Makefile that contain commands. As I suggested though, a comment can suffice. > If it is not an error, then by including one example of what the macro > looks like expanded in a comment, Jereon can debug in precisely the > way he wants for specific packages, while at the same time we use your > macro in general... > > Otherwise, I understand Jereon's point. Or I'm for autogenerating > our Makefile, which could then be manually edited when debugging. > Jereon has a very good point regarding debugging the sage build > system, which is perhaps hard to appreciate if you haven't spent days > doing it. I have, and at no point have I seen an issue like "the make recipe for this *specific* package isn't working correctly", because they're all the same for almost every package. The only examples where it gets tricky is in some of the the TOOLCHAIN packages but they are still built using the same commands. The trick with those has more to do with the order in which they're installed relative to each other, and this doesn't change any of that. All it changes is the generic recipe used for building/installing a single package, which is the same for virtually all of them. At worst, the only loss in clarity is that make templates look unfortunately a little like line noise. I'm not a perl fan either but I cut my teeth on it so I guess I'm not as bothered by that, especially if there's a clear example to light the way... Best, E >> >>> 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. >> >>> 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 :-) >> >> >> -- >> 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. > > > > -- > William (http://wstein.org) > > -- > 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. -- 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.
