>>I'm thinking about changing the way we build packages in separate >>directories. What we do now for tool chain packages is: >> >>mkdir -v ../binutils-build >>cd ../binutils-build >> >>../binutils-2.25.1/configure ... >> >> >>I'm thinking about changing that to: >> >>mkdir -v build >>cd build >> >>../configure ... >> > > Yes please. Less (unnecessary) steps for users. > > --DJ
Isn't it still the same number of steps: a mkdir; a cd and a configure all three of which will still be necessary steps for users? The fact that "configure" or. more correctly. the autotools, approach affords one the ability to build outside of a source tree and/or build for multiple architectures/platforms (even multiple users ?) from the same source tree somewhere within the visible filesystems, are "nice" ideas to plant into the minds of anyone coming new to "all this". Changing the way in which things are done, where there is a need to have a seperate "build" directory, isn't really being altered by the proposed change, indeed, one could argue that an "external build dir" reinforces the point being made, in respect of needing one. I'd also argue (probably too strong a word, if truth be told) that the fact that some users forget to remove the external build dirs is a justification for having it within the source tree could be countered by the observation that LFS doesn't explicity "remind" the user to get rid of the source directory with cd .. rm -fr package-x.y.z in each package's instructions, but merely gives out such advice in the generic "how to build" list I can't see any of those observations swaying the change as proposed by the way, but at least they've been aired. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
