Well, the question is not what I want to do, but what happens in the
context of an LFS/BLFS build by following the instructions.
From the point of view of an LFS builder, I understood (maybe
incorrectly) that I can set MAKEFLAGS to whatever I prefer and go using
the instructions as they are written. When a package has shown problems
with parallel makes, editors clearly advise so in the specific
instruction
on the page. This is done with all "make" and "make check" that are know
to need that.
Yes, but we also say: IF a problem occurs "the best way to proceed is
to drop back to a single processor build."
I suppose we could say that we do not recommend MAKEFLAGS or -jN, N>1
for the install phase.
Yes, I'm aware of that. The book has that covered. It was the workaround
I ended applying in this case and the problem with S-Lang is solved.
What I'm trying to convey is that from the point of view of a LFS reader
one could infer the opposite: "you are free to use MAKEFLAGS, because
'-j1' will properly be advised at each required spot".
Whether the recommendation "always 'make -j1 install' for all packages"
is explicitly reflected in the book or not is an editorial decision.
On your question about why using parallel install, I'd like to do so
while
developing/improving my scripts. I've been doing so with LFS and haven't
had trouble until S-Lang.
Generally wouldn't you be installing to a DESTDIR for that?
That's what I've been doing for my LFS-based scripts for the past two
months.
Now I do install using DESTDIR, pack it up to tar.zx, unpack it again to
copy to the filesystem while logging the untarred files with porg, so I
end up with the binaries installed on the system plus a nice
'package.tar.xz' that I can reinstall on the same or some other machine
without compiling, plus a nice set of auxiliary scripts to compile and
test, list files installed, remove packages, etc, etc.
This is a major refactor for all packages scripts plus adding several
new scripts (a simple package manager indeed). It takes a lot of time
and doing so you don't care much about a perfect installation until it
first simply works. You just want it fast in development, so I like the
idea that 'make install' uses MAKEFLAGS (which to be honest I didn't
think about until S-Lang).
I ran a
test and for slang, the install at -j1 takes about 14 seconds because it
wants to do some extra compilation in the install phase.
Good point!! Maybe it's that extra compilation at install phase that can
cause problems. That makes a lot of sense: you are still compiling at
'make install'...so you still need to keep '-j1'. Nice!
If you are
changing code, you have most of the files already compiled. My test
when I modified a C file then shows make install to take less than a
second at -j1.
I'm sticking to the general recommendation of deleting the source tree
before each build. My scripts do untar from source at every build
command I issue. And do so into a new timestamped directory so each
build is in a new clean tree but all previous logs and objects are kept
for comparison.
Sure, this is overkill, but warranties me (I believe) a consistent build
for even a tiny modification in the scripts (unless you don't mess up
with ccache...)
I think we are dealing with three different issues now:
* S-Lang needs 'make -j1 install' unconditionally...
* An explicit recommendation of doing 'make -j1 install' for either
S-Lang or all packages could be added to the book...
* How to set up or improve your development/building infrastructure.
To me, the first is not only solved but now explained. The second is an
editorial decision that I respect. And the third we could go for hours
but then we should change the subject of the thread ;-)
Thank you!
Alz.
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
