Noufal Ibrahim <[email protected]> writes:
[...] >> Step 2 says to run "python setup.py develop". Step 3 says to set up a >>virtualenv first, then to run "python setup.py develop". This a bit >>confusing and anybody who doesn't read ahead isn't going to do this >>properly. > > I'll clean this up. I've put these two as bullet points so that it doesn't seem sequential. I've also put a note in the main point. >> Step 4: did running make from the top-level directory not >> automatically build trilite for you? > > I never tried. I tried to follow the instructions in the README but > didn't notice this there. I'll check and if it works, add it. I've added this along and included the clang issues as a bullet point. >> >> Step 5: we should make it so that hacking the makefile is not >>required. Why did you have to do this? > > I initially tried to compile this against llvm-3.1 and the config script > for that was called llvm-config-3.1 (rather than just llvm-config which > was for 3.0 on my machine). I had to change this in the makefile. > > Under `check`, the `which` commands get wrong paths to clang/clang++. My > system llvm install is 3.0 and a `which` gets me /usr/bin/clang. This is > version 3.0 and won't work. I had to manually set them to my 3.2 > install. OTOH, this is just a check so it can't really hurt but it's > quite redundant especially if you use pass CXX while building no? I've mentioned this as is. I'll remove it when the Makefile is made more robust. >> We should probably put the "LLVM must be exactly version 3.2" >> requirement somewhere more prominent, rather than burying it down >> here. > > Yes. Very much so. It's what sucked away *most* of my time. I'll move it > up somewhere. I've put it at the top right under the build instructions heading. >> Step 6 and 7: I'm not clear on what we're doing here. > > Step 6 is what the docs originally had. Step 7 is what the build process > says in the end. > >> We should probably tell people to run "make test" if we want to verify >> that the tests run. If we want to get people up with a demo server to >> play with, maybe that should be in a separate section as it isn't >> really part of "Installing". Also, the test_basic directory is rather >> lean for a demo page now that we have most of the real tests in the >> new testing framework. Is it worth coming up with a dedicated demo >> directory? Or should we just direct people to configuration.mkd and >> let them figure it out on their own? > > You're right actually. Let me incorporate your suggestions as much as I > can and push out something cleaner. I'll post back when I do. I've tried to word it so that people can check whether their dxr is built and working properly. The names (tests/test_basic) etc. could be better. What do you think? -- Cordially, Noufal http://nibrahim.net.in _______________________________________________ dev-static-analysis mailing list [email protected] https://lists.mozilla.org/listinfo/dev-static-analysis
