[cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo

David Blaikie dblaikie at gmail.com
Thu Jul 21 14:16:26 PDT 2011


> It takes building and install clang on llvm.org and updating the script.
> ... I'll try to do this in the next week.

Cool - thanks. Strangely the (correct) script that Chris linked to his
reply has a clang path in PREPENDPATHDIRS but I don't really know what
it does with it. It looks like, potentially, clang could just be added
as an alternative without any changes to the machine itself (if that
path, /opt/clang-releases/llvm/bin, is usable) though given llvm-gcc's
limited future it might as well be removed.

[Chris]
> This would be really really great, the demo page is long need for a rewrite.  FYI the right path to the demo page is here:
> http://llvm.org/viewvc/llvm-project/www/trunk/demo/

Thanks - I'd gotten the link (& started thinking about the demo page
to see if it had 0x support, etc) from a recent clang checkin. It
looks like it's a clang copy & there's this file:
http://clang.llvm.org/demo/what%20is%20this%20directory.txt

It seems like that directory's a bit redundant & rather than having a
separate clang demo, we'd just update the llvm demo to use clang
instead of llvm-gcc, yes?

I'm wondering what would be the most practical way to work on
improvements. Small ones that don't require testing (if there's
already support for one command line argument, say, then adding more
shouldn't be painful/hard/risky) I can submit patches for & wait for
them to go live, but I wouldn't want to burden the list with lots of
patches as a means of developing/debugging/fixing changes when they go
live. I guess it would be easier for someone with direct access to the
machine to just hack at the script & check the changes live, then
checkin the result.

But I'm happy to have a crack at blind/unvalidated patches to improve
the functionality if that's useful.

- David



More information about the cfe-dev mailing list