From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Akira Yokosawa <akiyks@gmail.com>
Cc: perfbook@vger.kernel.org
Subject: Re: [GIT PULL FOR TEST v2] Another round of build script tweaks
Date: Fri, 6 May 2016 04:09:35 -0700 [thread overview]
Message-ID: <20160506110935.GA3593@linux.vnet.ibm.com> (raw)
In-Reply-To: <5864f027-b0dd-ee44-0005-c9fb289bc8cc@gmail.com>
On Fri, May 06, 2016 at 08:47:13AM +0900, Akira Yokosawa wrote:
> On 2016/05/05 06:21:53 -0700, Paul E. McKenney wrote:
> > On Thu, May 05, 2016 at 08:35:45AM +0900, Akira Yokosawa wrote:
> >> On 2016/05/05 0:39, Akira Yokosawa wrote:
> >>> Hi, Paul.
> >>>
> >>> Finally, I set up a GitHub account, and pushed v2 of the series
> >>> "Another round of build script tweaks".
> >>>
> >>> Please pull this into your local test branch and take time to see if
> >>> it actually works as you would expect. I'm fairly certain there would
> >>> be some regression, especially in the final commit 92ae43c3a72a
> >>> ("Further improvement of build scripts").
> >>> I'm also concerned about the fix of sig-theft.dot.
> >>>
> >>> Changes from v1.
> >>> Reorganized the entire series so that minor changes would come
> >>> first.
> >>>
> >>> Note: While I set up the account, I noticed a typo in my git-config
> >>> setting of user.email. My email address in the commit messages so
> >>> far was wrong. Sorry for the slip-up...
> >
> > So akiysw@gmail.com is wrong and akiyks@gmail.com is correct, right?
> > Looks like it from the email archives.
>
> Yes, that's right.
>
> > And in general, this looks to be good cleanup work. I do have some
> > questions and comments below.
>
> OK.
>
> >
> >>> Thanks, Akira
> >>>
> >>> ---
> >>> The following changes since commit 3f8bb7d620edee44637be00ba738761a4fc0732e:
> >>>
> >>> .gitignore: Add planned empty targets (2016-05-03 17:49:50 -0700)
> >>>
> >>> are available in the git repository at:
> >>>
> >>> https://github.com/akiyks/perfbook.git makefile-tweaks-v2
> >>>
> >>> for you to fetch changes up to 92ae43c3a72a3bcd7fd99ac681209ceafc6d7e65:
> >>>
> >>> Further improvement of build scripts (2016-05-04 23:43:06 +0900)
> >>>
> >>> ----------------------------------------------------------------
> >>> Akira Yokosawa (7):
> >>> Add font installation check
> >
> > Hmmm... The numbering is a bit inconsistent. And there are a lot of
> > build questions. We should place the trouble-shooting questions (1-4)
> > to a FAQ-build.txt file. Then have FAQ.txt file question #1's answer be
> > "See FAQ-build.txt". And then renumber the remaining FAQ.txt questions.
> >
> > Would you be willing to do this?
>
> Will do.
>
> > Also, please delete "have ever" from "If you have ever built" in the
> > first line of the answer.
>
> Will do
>
> >>> Add short name targets in Makefile
> >
> > For this one, the answer should also mention "make hb" for the
> > perfbook-hb.pdf that is useful for making hard-bound printouts.
>
> I see.
>
> >
> >>> sig-theft: Fix .dot source for dot - graphviz version 2.36.0
> >
> > Looks good!
> >
> >>> Make default target of "make" overridable
> >
> > This one should mention "hb" as well.
>
> You mean in FAQ-BUILD.txt?
Yes, please.
> >>> Makefile: Reorder rules
> >
> > Looks good!
> >
> >>> Makefile: Use wildcards
> >
> > Hmmm... I didn't know that you could do this. Something about having
> > started using "make" more than 30 years ago, I guess.
> >
> > For BIBSOURCES, please do "BIBSOURCES = bib/*.bib" on one line. I do
> > not expect multiple bibliography directories.
>
> Will do.
>
> > The dot files should probably be processed in the same way -- I added
> > them at different times, and apparently didn't make the processing
> > consistent. As long as you are fixing things, this would be good to
> > fix as well.
>
> So, the old one (dot -> eps) seems to be used because you want to convert
> the font to embeddable one. This is the way you want both .dot files
> (and other files to be added in the future) are handled?
I am not going to be that specific. ;-)
You are right, the fonts must be embeddable because otherwise the various
Internet printing services cannot handle the resulting PDF. Which might
well mean that the new one is broken -- I use the Internet printing
services only once every few years, so I would not have seen the bug.
> >>> Further improvement of build scripts
> >
> > I don't understand the point of interchanging the 1c and 2c rules.
>
> Ah, I put the one corresponding to the default target above.
> But there was no point doing that. Will fix.
>
> > I don't understand why perfbook.pdf no longer depends on extraction.
> > Ah, I see, the dependency is still there, but via perfbook.bbl and
> > perfbook_aux.
> >
> > Rather than create "perfbook_aux" and "extraction" files, wouldn't it be
> > more natural for perfbook.aux to depend on contrib.tex and origpub.tex,
> > and then have separate rules to generate each of these files? Ditto
> > or perfbook-bh_aux, and perfbook-1c_aux.
>
> Well, perfbook_aux seems unnecessary if perfbook.bbl is touched just
> before perfbook.pdf in runlatex.sh.
>
> contrib.tex and origpub.tex are tricky here. I'll try to explain.
>
> There are loops in dependency around perfbook_flat.tex
>
> perfbook_flat.tex requires an empty qqz.tex and up-to-date
> contrib.tex and origpub.tex for texexpand to work properly.
>
> Both contrib.tex and origpub.tex requires perfbook_flat.tex.
> contrib.tex also requires up-to-date qqz.tex.
>
> So at first glance, rules for contrib.tex and origpub.tex
> can be added, but that requires extraction to be a phony
> target.
>
> extraction is prerequisite for perfbook.aux.
> If you make it a phony target, the rule for perfbook.aux is
> always executed. That means runfirstlatex.run will run even
> if no source file is updated.
>
> Does the above explanation answer your question?
I had forgotten about that complication, thank you for the explanation.
> I may have missed something here. My original intention was
> to remove qqz.tex, contrib.tex and origpub.tex from the
> repository. I'd be happy if that can be done without any
> regression.
I would be fine with them being removed.
> > I do see the point of the "embedfonts" file -- nothing really to depend
> > on otherwise, since the files are fixed up in place. So I am OK with
> > that one.
> >
> > Thanx, Paul
>
> Is it OK to commit the fixes on the makefile-tweaks-v2 branch?
Make the above changes, and I will commit it. "git rebase -i" is
of course your friend for this task.
> And there is a related question I'd like to ask.
>
> Is the target perfbook_html actively maintained?
> When I tried this, I got a plenty of warning messages and the
> html files generated under perfbook_html seemed incomplete.
> Is there any prerequisite package for this to work?
The perfbook_html never did work very well. The people asking for it
eventually decided that perfbook-1c.pdf worked well enough for them.
I would be fine with perfbook_html being removed. Or fixed, just in
case someone has created a good latex-to-html conversion tool since
I last looked. When I last looked, the coversion looked great unless
you looked closely. It tended to corrupt some figures.
Thanx, Paul
> Thanks, Akira
> >
> >>> .gitignore | 1 -
> >>> FAQ.txt | 23 ++++
> >>> Makefile | 336 ++++++++++++++++++-------------------------------
> >>> count/sig-theft.dot | 17 +--
> >>> count/sig-theft.eps | 338 +++++++++++++++++++++++---------------------------
> >>> utilities/eps2pdf.sh | 12 ++
> >>> utilities/runlatex.sh | 9 ++
> >>> 7 files changed, 333 insertions(+), 403 deletions(-)
> >>>
> >>
> >> There was a regression in Makefile that prevents build after "make distclean".
> >> The fix is pushed.
> >>
> >> ---
> >> The following changes since commit 92ae43c3a72a3bcd7fd99ac681209ceafc6d7e65:
> >>
> >> Further improvement of build scripts (2016-05-04 23:43:06 +0900)
> >>
> >> are available in the git repository at:
> >>
> >> https://github.com/akiyks/perfbook.git makefile-tweaks-v2
> >>
> >> for you to fetch changes up to c496b1d5c45dec5401658449d049d2b4e70148c4:
> >>
> >> Fix regression in Makefile (2016-05-05 08:23:46 +0900)
> >>
> >> ----------------------------------------------------------------
> >> Akira Yokosawa (1):
> >> Fix regression in Makefile
> >>
> >> Makefile | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >
> >
>
next prev parent reply other threads:[~2016-05-06 11:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-04 15:39 [GIT PULL FOR TEST v2] Another round of build script tweaks Akira Yokosawa
2016-05-04 23:35 ` Akira Yokosawa
2016-05-05 13:21 ` Paul E. McKenney
2016-05-05 23:47 ` Akira Yokosawa
2016-05-06 11:09 ` Paul E. McKenney [this message]
2016-05-07 0:06 ` [GIT PULL v3] " Akira Yokosawa
2016-05-07 13:20 ` Paul E. McKenney
2016-05-07 15:23 ` Akira Yokosawa
2016-05-11 9:17 ` Paul E. McKenney
2016-05-11 14:34 ` [GIT PULL v4] " Akira Yokosawa
2016-05-14 9:55 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160506110935.GA3593@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akiyks@gmail.com \
--cc=perfbook@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox