Am 15.10.2017 um 14:29 schrieb Steven Schveighoffer:
On 10/13/17 4:29 PM, Sönke Ludwig wrote:
On Thu, 12 Oct 2017 14:41:51 -0400, Steven Schveighoffer wrote:
I can't for the life of me figure out how to get dub to call ddox with a
different --file-name-style option. How does it work?
I'd imagine for those building ddox on Windows or Mac, this would be a
Hm, this is actually something that is not supported by the current
built-in functionality "-b ddox". The only possibility to customize it
is to either use a different doc tool, or using the ddoxFilterArgs
experimental option, but that doesn't work for output options.
On my mac, the filenames are case insensitive, so I get a bad build of
ddox (I have a factory function called nullDev that builds a type called
NullDev, which result in the same filename). This kind of makes the
whole feature useless, no?
You can of course just take the generated docs.json file and call
dub <br>ddox -- generate-htmldirectly.
I'm sure there's a typo here, dub ddox is not a command, and ddox I'm
guessing is buried somewhere in dub's infrastructure?
Sorry, you are right,
dub run ddox -- ... is the right command.
The question is if it makes sense to add another experimental option
specific to ddox ("ddoxGenerateArgs"), or to work towards a more
general solution for integrating documentation generators.
I would recommend a way to simply pass flags as-is to any build command.
Sort of like dmd -L passes that parameter verbatim to the linker.
In this case, ddox is ddox. There is no worry about cross-platform
The specific thing to Ddox is that it currently has a separate filter
step, and it would be necessary to somehow be able to make certain flags
conditional to a certain doc tool, so that packages can for example
still be built in a generic way on code.dlang.org (in the future).
At some point I'd like to reuse the "DUB plugin as a DUB package" idea
to sport a new "dub doc" command that can be extended to support any
tool, regardless of its command line syntax. That would also allow using
a natural syntax to configure the tool within the package recipe.
A further alternative, could ddox default to a different file naming
scheme for MacOS and Windows?
Or rather on Mac/Windows and Linux/others. Makes sense!