CG chapter 3, first draft

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

CG chapter 3, first draft

Mark Polesky
CG chapter 3, first draft

I'm posting this on frogs instead of -devel since I think
more of the target audience is here...

Here's a draft of the (hopefully) new CG compiling
chapter.  It's too big for the mailing list, so I'm
hosting it myself:

http://www.markpolesky.com/norobots/compiling_new.itexi
http://www.markpolesky.com/norobots/compiling_new.itexi.html

Right now, it's all in one file for convenience---I'll
patch it properly with basic-compile.itexi etc. later.
And the nodes for chapters 1 and 2 are just temporary
placeholders.  I added quite a bit of new text, and I'm
curious to know how well it reads, and whether you guys
think it's an improvement over the current chapter.

Also, let me know if you find any factual inaccuracies;
hopefully there aren't any, but some of this is confusing
for me too!

Any other comments or suggestions are of course
appreciated.

Thanks.
- Mark


     

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: CG chapter 3, first draft

Graham Percival
On Tue, Jan 19, 2010 at 7:30 AM, Mark Polesky <[hidden email]> wrote:
> http://www.markpolesky.com/norobots/compiling_new.itexi.html
>
> Right now, it's all in one file for convenience---I'll
> patch it properly with basic-compile.itexi etc. later.

Just to check, do you know that basic-compile.itexi is the stuff that
gets turned into INSTALL.txt ?  It's included in
Documentation/topdocs/install.texi

I mention this because AFAIK nobody's really thought about what
material should be in the CG only, vs. what material should be shared
with INSTALL.txt.  The text file should contain enough info to compile
from scratch (if somebody downloads the source tarball), but nobody's
really thought about what additional info, if any, would be
appropriate to add or subtract.


> Also, let me know if you find any factual inaccuracies;
> hopefully there aren't any, but some of this is confusing
> for me too!

Speaking of facts, I think we could simplify a few things.  I think
that guile 1.8.2 is fairly old, as is ghostscript 8.15.  Instead of
saying "guile 1.8.1 with patch x and y, and ghostscript 8.15 with
patch z", why not just specify the later version number?

Similarly, let's stop talking about g++ 3.4; just say 4.0 or
higher.... I mean, if somebody complains that it doesn't work in 3.4,
we're (probably) not going to actually fix that.

Since we have links for everything else, let's add a link for Imagemagick.

It would be *really* nice if we stopped telling people to look at
input/regression/utf-8.ly for hints about fonts, and had that info in
the install chapter directly.

3.3

Don't tell people about the source snapshot.  The whole point about
encouraging tarballs is that they're a known point in time --
particularly, a believed-to-be-compilable point in time.  If they want
to use the full bleeding edge, they should use git.

I personally would just give them the @rweb{Source} link.  If you
really want to give the link to inuxaudio, I guess you could, but
it'll look better inside a

@example
@uref{...}
@end example

I really don't think the warnings about untarring are necessary.
Newbies aren't supposed to screw with source tarballs.


3.4.1

Who's going to update the list of generated files whenever they
change?  Also, I don't believe that autogen.sh creates an out/ dir.

I'd rather just say that it creates a number of files and directories
to aid configuration (or something like that).


3.4.2

as Carl or John already pointed out, you don't need to run ./configure
if you run ./autogen.sh.

BTW, ./configure is *known* to not check all doc requirements.  A
warning here would definitely be appropriate.


Changing the install directory doesn't force a full recompile, so
changing the --prefix after compiling isn't a big deal.  You also
don't need to create the directory; as long as you have write
permission to the higher directory, make install will create the
install dir just fine.


The technical term for separate build directory is "out-of-tree build".
Note that in some cases, you'll need to run
  make distclean
in the main source dir before you can successfully do the out-of-tree
configure and make.

I'd put ./configure --help at the top of this subsection.


3.5.1

You don't need to run "make clean" unless you specifically want to.
If the build system worked perfectly, you'd *never* need to run make
clean.  As it is, "make clean" is only needed once every 2-3 months
(from empirical evidence).

I'd mention -jX somewhere, since that's a very commonly-used and
desired option, with most people having 2 or 4 cores.

3.6.2

sweet mao, we don't want people running doc-clean!!!

I wouldn't bother mentioning info.  If somebody wants to trawl through
the make targets, they'll find it... but really, who on earth wants
info?

I'd put the -j3 CPU_COUNT=3 earlier in the section.  Again, it's
getting more and more useful with the direction that cpu manufacturers
are going.


Cheers,
- Graham

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: [frogs] CG chapter 3, first draft

Mark Polesky
Here are the links again:
http://www.markpolesky.com/norobots/compiling_new.itexi
http://www.markpolesky.com/norobots/compiling_new.itexi.html

Graham Percival wrote:
> Just to check, do you know that basic-compile.itexi [...]
> INSTALL.txt ? [...]
>
> [...] AFAIK nobody's really thought about what material
> should be in the CG only, vs. what material should be
> shared with INSTALL.txt.  [...]

Yes, I know.  I'll decide that later.  For the moment, I'd
like to get the CG-specific stuff out of the way.

> I think that guile 1.8.2 is fairly old, as is ghostscript
> 8.15.  Instead of saying "guile 1.8.1 with patch x and y,
> and ghostscript 8.15 with patch z", why not just specify
> the later version number?

Done.

> Similarly, let's stop talking about g++ 3.4; just say 4.0
> or higher.... I mean, if somebody complains that it
> doesn't work in 3.4, we're (probably) not going to
> actually fix that.

Not done.  I met with some resistance on -devel.  Feel free
to step in there.
http://lists.gnu.org/archive/html/lilypond-devel/2010-01/msg00499.html

> Since we have links for everything else, let's add a link
> for Imagemagick.

Done.

> It would be *really* nice if we stopped telling people to
> look at input/regression/utf-8.ly for hints about fonts,
> and had that info in the install chapter directly.

Done.  But---what's the RPM equivalent of "apt-get install"?
As it stands the RPM stuff starts with "taipeifonts", as if
it were a command.

> 3.3
>
> Don't tell people about the source snapshot.  The whole
> point about encouraging tarballs is that they're a known
> point in time -- particularly, a believed-to-be-compilable
> point in time.  If they want to use the full bleeding
> edge, they should use git.

Hmm.  Certainly some readers might be curious to see the
snapshot without bothering with Git.  I don't think that
including a quick link to it is going to harm anybody.  How
strongly do you feel about this?  I kind of like it there.

> I personally would just give them the @rweb{Source} link.
> If you really want to give the link to linuxaudio, I guess
> you could, but it'll look better inside a
>
> @example
> @uref{...}
> @end example

Done.

> I really don't think the warnings about untarring are
> necessary.  Newbies aren't supposed to screw with source
> tarballs.

Yes, but newbies might not *know* that they're not supposed
to screw with source tarballs.  Again, I don't see any harm
in including the warning.  I don't think those two sentences
are a big obstacle to the overall flow.

> Who's going to update the list of generated files whenever
> they change?  Also, I don't believe that autogen.sh
> creates an out/ dir.
>
> I'd rather just say that it creates a number of files and
> directories to aid configuration (or something like that).

Done.

> as Carl or John already pointed out, you don't need to run
> ./configure if you run ./autogen.sh.

Okay, I changed "you need to run" to "you should run".

> BTW, ./configure is *known* to not check all doc
> requirements.  A warning here would definitely be
> appropriate.

Which doc requirements does it not check?  I know that
./configure doesn't issue an ERROR when missing a doc
requirement, but it was my assumption that it should issue a
WARNING.  This much is clear in the text (I thought), so let
me know what I'm missing.

> Changing the install directory doesn't force a full
> recompile, so changing the --prefix after compiling isn't
> a big deal.

Okay, I removed the portentous sentence.

> You also don't need to create the directory; as long as
> you have write permission to the higher directory, make
> install will create the install dir just fine.

Hmm.  I didn't think the paragraph implies that the directory
needs to exist.  Should I add "(or within)" like this?

  `make install' will only succeed if the installation
  prefix points to (or within) a directory where you have
  write permission (such as your home directory).

> The technical term for separate build directory is
> "out-of-tree build".  Note that in some cases, you'll need
> to run make distclean in the main source dir before you
> can successfully do the out-of-tree configure and make.

Okay, I added a note about it.

> I'd put ./configure --help at the top of this subsection.

Done.

> 3.5.1
>
> You don't need to run "make clean" unless you specifically
> want to.  If the build system worked perfectly, you'd
> *never* need to run make clean.  As it is, "make clean" is
> only needed once every 2-3 months (from empirical
> evidence).

Oh.  I must have over-interpreted this post of yours:
http://lists.gnu.org/archive/html/lilypond-devel/2009-12/msg00496.html

> I'd mention -jX somewhere, since that's a very
> commonly-used and desired option, with most people having
> 2 or 4 cores.

You mean specifically for `make' and not `make doc'?  If so,
could you write a little paragraph?  I don't really know how
it works.  I added a node.

> 3.6.2
>
> sweet mao, we don't want people running doc-clean!!!

Why not?  You make it sound like there's something I don't
know.  Something that should be mentioned, perhaps...

> I wouldn't bother mentioning info.  If somebody wants to
> trawl through the make targets, they'll find it... but
> really, who on earth wants info?

Apparently John does; he's the one who wrote it:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;h=0c9af42

> I'd put the -j3 CPU_COUNT=3 earlier in the section.
> Again, it's getting more and more useful with the
> direction that cpu manufacturers are going.

Done.

Thanks for your input.  Looking forward to more!
- Mark


     

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: [frogs] CG chapter 3, first draft

Graham Percival
On Fri, Jan 22, 2010 at 4:36 AM, Mark Polesky <[hidden email]> wrote:
> Graham Percival wrote:
>> Similarly, let's stop talking about g++ 3.4; just say 4.0
>> or higher.... I mean, if somebody complains that it
>> doesn't work in 3.4, we're (probably) not going to
>> actually fix that.
>
> Not done.  I met with some resistance on -devel.  Feel free
> to step in there.
> http://lists.gnu.org/archive/html/lilypond-devel/2010-01/msg00499.html

Me?  I don't know how this stuff works.  Go with whatever Patrick says.

>> It would be *really* nice if we stopped telling people to
>> look at input/regression/utf-8.ly for hints about fonts,
>> and had that info in the install chapter directly.
>
> Done.  But---what's the RPM equivalent of "apt-get install"?

Depends on the distro.  Everybody has their own.  Just list the
package names; anybody fussing with this stuff should be able to
figure it out, anyway.

>> 3.3
>>
>> Don't tell people about the source snapshot.
>
> Hmm.  Certainly some readers might be curious to see the
> snapshot without bothering with Git.  I don't think that
> including a quick link to it is going to harm anybody.  How
> strongly do you feel about this?  I kind of like it there.

I strongly feel that I will (continue to) get royally pissed off when
we receive emails saying "random
snapshop-a785b67c4g6d56ef675eedc86c86e.tar.bz2 doesn't work!"
(for bonus marks, find the illegal character in the above string)

If somebody discovers the snapshot link on their own, fine.  But
having a link in the CG seems to be asking for trouble.  Packagers
should work from compilable-tarballs (at least compilable on linux);
developers should work from git (so they can get easy bugfixes).
Snapshots combine the worst of both worlds, with none of the benefits.

If you still really want to have the link there, fine, but when
somebody runs into trouble with a snapshot, I'm going to take it out
on them.  IMO, one of the implied trade-offs of yelling at people for
doing stupid things is that the docs should be written so that it's
very hard to do stupid things.

Having "use at your own risk" isn't sufficient discouragement, IMO.


BTW, why use that gunzip command?  Just use
  tar -xj

>> Who's going to update the list of generated files whenever
>> they change?  Also, I don't believe that autogen.sh
>> creates an out/ dir.
>>
>> I'd rather just say that it creates a number of files and
>> directories to aid configuration (or something like that).
>
> Done.
>
>> as Carl or John already pointed out, you don't need to run
>> ./configure if you run ./autogen.sh.
>
> Okay, I changed "you need to run" to "you should run".
>
>> BTW, ./configure is *known* to not check all doc
>> requirements.  A warning here would definitely be
>> appropriate.
>
> Which doc requirements does it not check?  I know that
> ./configure doesn't issue an ERROR when missing a doc
> requirement, but it was my assumption that it should issue a
> WARNING.  This much is clear in the text (I thought), so let
> me know what I'm missing.
>
>> Changing the install directory doesn't force a full
>> recompile, so changing the --prefix after compiling isn't
>> a big deal.
>
> Okay, I removed the portentous sentence.
>
>> You also don't need to create the directory; as long as
>> you have write permission to the higher directory, make
>> install will create the install dir just fine.
>
> Hmm.  I didn't think the paragraph implies that the directory
> needs to exist.  Should I add "(or within)" like this?
>
>  `make install' will only succeed if the installation
>  prefix points to (or within) a directory where you have
>  write permission (such as your home directory).
>
>> The technical term for separate build directory is
>> "out-of-tree build".  Note that in some cases, you'll need
>> to run make distclean in the main source dir before you
>> can successfully do the out-of-tree configure and make.
>
> Okay, I added a note about it.
>
>> I'd put ./configure --help at the top of this subsection.
>
> Done.
>
>> 3.5.1
>>
>> You don't need to run "make clean" unless you specifically
>> want to.  If the build system worked perfectly, you'd
>> *never* need to run make clean.  As it is, "make clean" is
>> only needed once every 2-3 months (from empirical
>> evidence).
>
> Oh.  I must have over-interpreted this post of yours:
> http://lists.gnu.org/archive/html/lilypond-devel/2009-12/msg00496.html
>
>> I'd mention -jX somewhere, since that's a very
>> commonly-used and desired option, with most people having
>> 2 or 4 cores.
>
> You mean specifically for `make' and not `make doc'?  If so,
> could you write a little paragraph?  I don't really know how
> it works.  I added a node.
>
>> 3.6.2
>>
>> sweet mao, we don't want people running doc-clean!!!
>
> Why not?  You make it sound like there's something I don't
> know.  Something that should be mentioned, perhaps...
>
>> I wouldn't bother mentioning info.  If somebody wants to
>> trawl through the make targets, they'll find it... but
>> really, who on earth wants info?
>
> Apparently John does; he's the one who wrote it:
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;h=0c9af42
>
>> I'd put the -j3 CPU_COUNT=3 earlier in the section.
>> Again, it's getting more and more useful with the
>> direction that cpu manufacturers are going.
>
> Done.
>
> Thanks for your input.  Looking forward to more!
> - Mark
>
>
>
>

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: [frogs] CG chapter 3, first draft

Graham Percival
In reply to this post by Mark Polesky
Sorry, I'm using the gmail interface and somehow managed to hit a
"send" keyboard shortcut.  I left my netbook at home while I was
teaching.


I use
  tar -xjf lilypond-x.y.z-a.tar.bz2
for the tar.gz (do we even distribute those?), you'd change the j to a z.


On Fri, Jan 22, 2010 at 4:36 AM, Mark Polesky <[hidden email]> wrote:
>> as Carl or John already pointed out, you don't need to run
>> ./configure if you run ./autogen.sh.
>
> Okay, I changed "you need to run" to "you should run".

well... ok.  Even that's not true, but it's easier than explaining "if
some time has passed since the last time you ran ./configure or
./autogen.sh, then run ./configure".


>> BTW, ./configure is *known* to not check all doc
>> requirements.  A warning here would definitely be
>> appropriate.
>
> Which doc requirements does it not check?  I know that
> ./configure doesn't issue an ERROR when missing a doc
> requirement, but it was my assumption that it should issue a
> WARNING.

Maoed if I can remember, but I had a good reason for adding
http://code.google.com/p/lilypond/issues/detail?id=775

it might have been some of the texinfo fonts... no, wait, it was
imagemagick or netpbm or something like that... whatever.

I mean, yes, it *should* issue a warning, but it doesn't for some
doc-building requirements.


>> You also don't need to create the directory; as long as
>> you have write permission to the higher directory, make
>> install will create the install dir just fine.
>
> Hmm.  I didn't think the paragraph implies that the directory
> needs to exist.  Should I add "(or within)" like this?

hmm, reading it now, I agree that it doesn't.  I think I was confused
about the "intallation prefix"... I mean, if $HOME/usr/ doesn't exist,
make install will happily create it for you.


>> 3.5.1
>>
>> You don't need to run "make clean" unless you specifically
>> want to.  If the build system worked perfectly, you'd
>> *never* need to run make clean.  As it is, "make clean" is
>> only needed once every 2-3 months (from empirical
>> evidence).
>
> Oh.  I must have over-interpreted this post of yours:
> http://lists.gnu.org/archive/html/lilypond-devel/2009-12/msg00496.html

That was a list of things to do to totally clean out your system and
start from fresh.


>> I'd mention -jX somewhere, since that's a very
>> commonly-used and desired option, with most people having
>> 2 or 4 cores.
>
> You mean specifically for `make' and not `make doc'?  If so,
> could you write a little paragraph?  I don't really know how
> it works.  I added a node.

"
To build with multiple CPUs, add -jX to the command, where X is one
more than the number of cores you have.  For examine, a typical
Core2Duo machine would use:

    make -j3
"



>> 3.6.2
>>
>> sweet mao, we don't want people running doc-clean!!!
>
> Why not?  You make it sound like there's something I don't
> know.  Something that should be mentioned, perhaps...

It forces a complete rebuild, thereby taking 30 minutes to 3 hours,
instead of 1-2 minutes to only generate the changed stuff.

Cheers,
- Graham

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: [frogs] CG chapter 3, first draft

Graham Percival
In reply to this post by Graham Percival
On Fri, Jan 22, 2010 at 8:10 PM, Graham Percival
<[hidden email]> wrote:

> On Fri, Jan 22, 2010 at 4:36 AM, Mark Polesky <[hidden email]> wrote:
>> Graham Percival wrote:
>>> Similarly, let's stop talking about g++ 3.4; just say 4.0
>>> or higher.... I mean, if somebody complains that it
>>> doesn't work in 3.4, we're (probably) not going to
>>> actually fix that.
>>
>> Not done.  I met with some resistance on -devel.  Feel free
>> to step in there.
>> http://lists.gnu.org/archive/html/lilypond-devel/2010-01/msg00499.html
>
> Me?  I don't know how this stuff works.  Go with whatever Patrick says.
>
>>> It would be *really* nice if we stopped telling people to
>>> look at input/regression/utf-8.ly for hints about fonts,
>>> and had that info in the install chapter directly.
>>
>> Done.  But---what's the RPM equivalent of "apt-get install"?
>
> Depends on the distro.  Everybody has their own.  Just list the
> package names; anybody fussing with this stuff should be able to
> figure it out, anyway.
>
>>> 3.3
>>>
>>> Don't tell people about the source snapshot.
>>
>> Hmm.  Certainly some readers might be curious to see the
>> snapshot without bothering with Git.  I don't think that
>> including a quick link to it is going to harm anybody.  How
>> strongly do you feel about this?  I kind of like it there.
>
> I strongly feel that I will (continue to) get royally pissed off when
> we receive emails saying "random
> snapshop-a785b67c4g6d56ef675eedc86c86e.tar.bz2 doesn't work!"
> (for bonus marks, find the illegal character in the above string)
>
> If somebody discovers the snapshot link on their own, fine.  But
> having a link in the CG seems to be asking for trouble.  Packagers
> should work from compilable-tarballs (at least compilable on linux);
> developers should work from git (so they can get easy bugfixes).
> Snapshots combine the worst of both worlds, with none of the benefits.
>
> If you still really want to have the link there, fine, but when
> somebody runs into trouble with a snapshot, I'm going to take it out
> on them.  IMO, one of the implied trade-offs of yelling at people for
> doing stupid things is that the docs should be written so that it's
> very hard to do stupid things.
>
> Having "use at your own risk" isn't sufficient discouragement, IMO.
>
>
> BTW, why use that gunzip command?  Just use
>  tar -xj
>
>>> Who's going to update the list of generated files whenever
>>> they change?  Also, I don't believe that autogen.sh
>>> creates an out/ dir.
>>>
>>> I'd rather just say that it creates a number of files and
>>> directories to aid configuration (or something like that).
>>
>> Done.
>>
>>> as Carl or John already pointed out, you don't need to run
>>> ./configure if you run ./autogen.sh.
>>
>> Okay, I changed "you need to run" to "you should run".
>>
>>> BTW, ./configure is *known* to not check all doc
>>> requirements.  A warning here would definitely be
>>> appropriate.
>>
>> Which doc requirements does it not check?  I know that
>> ./configure doesn't issue an ERROR when missing a doc
>> requirement, but it was my assumption that it should issue a
>> WARNING.  This much is clear in the text (I thought), so let
>> me know what I'm missing.
>>
>>> Changing the install directory doesn't force a full
>>> recompile, so changing the --prefix after compiling isn't
>>> a big deal.
>>
>> Okay, I removed the portentous sentence.
>>
>>> You also don't need to create the directory; as long as
>>> you have write permission to the higher directory, make
>>> install will create the install dir just fine.
>>
>> Hmm.  I didn't think the paragraph implies that the directory
>> needs to exist.  Should I add "(or within)" like this?
>>
>>  `make install' will only succeed if the installation
>>  prefix points to (or within) a directory where you have
>>  write permission (such as your home directory).
>>
>>> The technical term for separate build directory is
>>> "out-of-tree build".  Note that in some cases, you'll need
>>> to run make distclean in the main source dir before you
>>> can successfully do the out-of-tree configure and make.
>>
>> Okay, I added a note about it.
>>
>>> I'd put ./configure --help at the top of this subsection.
>>
>> Done.
>>
>>> 3.5.1
>>>
>>> You don't need to run "make clean" unless you specifically
>>> want to.  If the build system worked perfectly, you'd
>>> *never* need to run make clean.  As it is, "make clean" is
>>> only needed once every 2-3 months (from empirical
>>> evidence).
>>
>> Oh.  I must have over-interpreted this post of yours:
>> http://lists.gnu.org/archive/html/lilypond-devel/2009-12/msg00496.html
>>
>>> I'd mention -jX somewhere, since that's a very
>>> commonly-used and desired option, with most people having
>>> 2 or 4 cores.
>>
>> You mean specifically for `make' and not `make doc'?  If so,
>> could you write a little paragraph?  I don't really know how
>> it works.  I added a node.
>>
>>> 3.6.2
>>>
>>> sweet mao, we don't want people running doc-clean!!!
>>
>> Why not?  You make it sound like there's something I don't
>> know.  Something that should be mentioned, perhaps...
>>
>>> I wouldn't bother mentioning info.  If somebody wants to
>>> trawl through the make targets, they'll find it... but
>>> really, who on earth wants info?
>>
>> Apparently John does; he's the one who wrote it:
>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;h=0c9af42
>>
>>> I'd put the -j3 CPU_COUNT=3 earlier in the section.
>>> Again, it's getting more and more useful with the
>>> direction that cpu manufacturers are going.
>>
>> Done.
>>
>> Thanks for your input.  Looking forward to more!
>> - Mark
>>
>>
>>
>>
>

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: [frogs] CG chapter 3, first draft

Mark Polesky
The links:
http://www.markpolesky.com/norobots/compiling_new.itexi
http://www.markpolesky.com/norobots/compiling_new.itexi.html

Graham Percival wrote:
> I use
>   tar -xjf lilypond-x.y.z-a.tar.bz2
> for the tar.gz (do we even distribute those?), you'd
> change the j to a z.

As far as I know, we *only* distribute those.  Where do you
see a lilypond[*].tar.bz2 file?

>> Okay, I changed "you need to run" to "you should run".
>
> well... ok.  Even that's not true, but it's easier than
> explaining "if some time has passed since the last time
> you ran ./configure or ./autogen.sh, then run
> ./configure".

Isn't it a good idea to run it before your first compile?
How is that not true?

>>> BTW, ./configure is *known* to not check all doc
>>> requirements.  A warning here would definitely be
>>> appropriate.
>
> I mean, yes, it *should* issue a warning, but it doesn't
> for some doc-building requirements.

Okay.

> " To build with multiple CPUs, add -jX to the command,
> where X is one more than the number of cores you have.
> For examine, a typical Core2Duo machine would use:
>
>     make -j3 "

Added.

>>> 3.6.2
>>>
>>> sweet mao, we don't want people running doc-clean!!!
>>
>> Why not?  You make it sound like there's something I
>> don't know.  Something that should be mentioned,
>> perhaps...
>
> It forces a complete rebuild, thereby taking 30 minutes to
> 3 hours, instead of 1-2 minutes to only generate the
> changed stuff.

Boy, I wish that had been made clear to me earlier!  I've
started a new thread on -devel to clarify these sorts of
things:
http://lists.gnu.org/archive/html/lilypond-devel/2010-01/msg00516.html

- Mark


     

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: [frogs] CG chapter 3, first draft

Graham Percival
On Fri, Jan 22, 2010 at 04:17:17PM -0800, Mark Polesky wrote:

> The links:
> http://www.markpolesky.com/norobots/compiling_new.itexi
> http://www.markpolesky.com/norobots/compiling_new.itexi.html
>
> Graham Percival wrote:
> > I use
> >   tar -xjf lilypond-x.y.z-a.tar.bz2
> > for the tar.gz (do we even distribute those?), you'd
> > change the j to a z.
>
> As far as I know, we *only* distribute those.  Where do you
> see a lilypond[*].tar.bz2 file?

Nowhere, I was just making up my normal command-line for dealing
with compressed files.  We could save a bit of space+bandwidth by
switching to .tar.bz2, but this is hardly an urgent issue.

> >> Okay, I changed "you need to run" to "you should run".
> >
> > well... ok.  Even that's not true, but it's easier than
> > explaining "if some time has passed since the last time
> > you ran ./configure or ./autogen.sh, then run
> > ./configure".
>
> Isn't it a good idea to run it before your first compile?
> How is that not true?

./autogen.sh automatically runs ./configure.

Cheers,
- Graham

---
----
Join the Frogs!