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.
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.
