On Wed, Jan 31, 2018 at 5:27 PM, Erik Bray <erik.m.b...@gmail.com> wrote: > 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.
Oh, another comment to this point though. This loops over a variable called NORMAL_PACKAGES (for lack of a better name; suggestions welcome) which is just a list of the names of packages which are built/installed with the "normal" commands (i.e. running sage-spkg). This is as opposed to "pip" and "script" packages. Anyways, speaking of comments, if you wanted to debug a specific package you could, as William suggested, copy the example and comment the package out from NORMAL_PACKAGES, thus excluding it from the macro expansion. >> 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.
