On 05/09/14 19:20, Villum Sejersen wrote:
On 04-09-2014 12:17, James wrote:
On 04/09/14 08:46, Villum Sejersen wrote:
On 04-09-2014 06:46, David Kastrup wrote:
Villum Sejersen<v...@privat.tdcadsl.dk> writes:
root@Villums14:/usr/local/src/lilypond/build# git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
But since sept. 2.:
root@Villums14:/usr/local/src/lilypond/build# make --silent
make[1]: *** No rule to make target
'/usr/local/src/lilypond/lily/include/ly-smobs.icc', needed by
'out/translator-dispatch-list.o'. Stop.
/usr/local/src/lilypond/stepmake/stepmake/generic-targets.make:6:
recipe for target 'all' failed
make: *** [all] Error 2
make clean
Sometimes dependencies change and you cannot merely recompile.
Thank you very much.
I did not think of this, because ./autogen.sh did not report any
errors.
'make clean' was not sufficient alone;
For some obscure reason I had to do a 'make distclean' first.
But now both application and docs compile. On my old AMD Athlon X2
the latter takes about an hour. :) Do you use an 'out of tree' build?
I believe yes, though I really don't exactly know what you are
questioning.
I never try but to compile the origin/master, not anything else. I
have no other branches.
1. autogen.sh --noconfigure
What's the purpose of this option? In my experience, it achieves
absolutely nothing:
root@Villums14:/usr/local/src/lilypond# ./autogen.sh --noconfigure
processing .
Running autoconf ...
Skipping configure process.
root@Villums14:/usr/local/src/lilypond#
It allows you to then run the ../configure inside the build dir that you
have just created.
2. mkdir build
3. cd build
I usually never totally replace the build directoy. If that's
necessary, it is in my experience also necessary to retrieve the whole
git source,and begin completely afresh!
There is no build directory to start in a clean git with so I am not
sure what you are 'replacing' here. Your experience is odd. As I do this
process about 2 - 3 times most days
4 ../configure --disable-optimising
This option has never been necessary in my setup.
No but the disable-optimising as far as I am told makes for a more
rigourous 'make' (I don't pretend to know but as I test most of the
patches that get submitted, I am asked to use this option for the most
thorough testing of patches). Don't use it if you don't want to.
5. make etc. etc.
That way I can just destroy the build dir and start again without
worrying too much about having to make clean or dist clean - at least
it seems to be that way for me. We mention this method in the
LilyPond Contributor Guide.
Well, I am not a contributor, perhaps except for over the years
stumbling on a few small bugs...
James
My setup perhaps is unusual: It's a plain debian testing, /not/ ubuntu.
So is mine.
Actually mine at work is, mine at home is Linux Mint I forget which.
Creating an out of tree build has saved me hours of frustrating trying
to clean up a borked make, I just cd back into the top level, delete the
build dir and start again.
James
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
