On 6/25/07, Steve Long <[EMAIL PROTECTED]> wrote:
Petteri Räty wrote:
>> Maybe the flag needs to be renamed/split up to clarify it's meaning,
>> it's too generic in it's current form (many people enable it blindly and
>> don't really have any clue what the result is).
>> Like using USE=apidoc for API documentation, USE=extradoc for extra
>> user documentation (controlling PDF generation and stuff like that),
>> USE=rebuild-docs to replace pregenerated documentation with
>> updated/regenerated versions (like the gtk-doc issue), and so on (don't
>> know what other use cases there are for USE=doc currently).
>>
>> It's a large change, but USE=doc has been a significant problem for
>> quite a while already (circular deps anyone?)
>>
>
> That does sound like a good idea.
>
++ I was only thinking of the programmer:user difference, since code docs
tend to pull in a lot of stuff, where as end-user docs are normally
supplied in an easier format (eg not dox ;) rebuild-docs as a one-shot flag
is great.
Would there be a way to control what kind of markup is output (assuming a
package supports it)? For example, to specify that files should be for
text-only or graphical browser (where both would be the default.) XeTeX --
PS -- PDF is another along those lines.
I can just feel a USE expansion coming on.
DOC="none pdf txt man ps html info all rebuild" sounds like just a
bunch for starters.
Any votees?
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil [EMAIL PROTECTED]"[(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
