Closed Bug 1176617 Opened 9 years ago Closed 9 years ago

Problems in getting started (mostly documentation)

Categories

(Webtools Graveyard :: DXR, defect)

defect
Not set
normal

Tracking

(firefox41 affected)

RESOLVED WONTFIX
Tracking Status
firefox41 --- affected

People

(Reporter: djc, Unassigned)

Details

From my Friday afternoon "rant", on IRC:

16:25 < djc> when I run make in dxr, I get an error that trilite doesn't have a 'release' target
16:26 < djc> ah, so I guess I have to update the submodule myself
16:26 < djc> would a pull request adding a little git submodule thingy to the Makefile be 
             acceptable?
16:27 < djc> e.g. trilite/makefile: git submodule init && git submodule update
16:27 < djc> or a docs update...
16:28 < djc> also, sqlite headers aren't mentioned in the dxr dependencies
16:28 < djc> neither is a dependency on hg to pull in re2
16:29 < djc> (I'm basically trying to follow deployment.html here, from a CentOS machine)
16:33 < djc> next problem: the phantomjs-1.9.7 package on bitbucket throws a 403 Forbidden
16:44 < djc> solved this by upgrading the dependency in lockdown.js to 1.9.8
16:44 < new_one> djc: are you setting this up in the vagrant box?
16:44 < djc> no, a vanilla CentOS VM
16:45 < new_one> the vagrant box runs this script to install dependencies: 
                 https://github.com/mozilla/dxr/blob/master/vagrant_provision.sh
16:45 < new_one> you may be able to follow that to see exactly what's required
16:46 < djc> well, but that's debian-oriented
16:46 < djc> and anyway, the documentation for building from source should be correct or corrected, 
             right? :)
16:47 < new_one> I think the guide assumes you're running in vagrant
16:49 < new_one> but keep updating on how it's going for you, perhaps we will add a section to the 
                 doc
16:49 < djc> deployment.html has "Since you're no longer using the Vagrant VM"
16:49 < djc> so I'm pretty sure this stuff should work outside of a vagrant environment
16:57 < djc> also not sure where the dxr executable is supposed to come from
16:57 < djc> when I run python setup.py develop, I get a dxr-build.py and a dxr-serve.py
16:58 < djc> which is clear enough, but doesn't match what getting-started.html says
16:59 < djc> also, with that setup, libtrilite.so is not found when trying to run dxr-build.py
17:09 < djc> so now following getting-started.html
17:10 < djc> I didn't see anyway the libtrilite.so is supposed to land on a path the scripts can 
             find
17:10 < djc> so set LD_PRELOAD_PATH by hand, as the makefile does
17:10 < djc> next problem is config... using a config file with minimal stuff doesn't work as 
             advertised
17:11 < djc> so first I had to come up with DXR.target_folder (those error messages could be a bit 
             nicer than a Python traceback, btw)
17:11 < djc> that made some amount of sense to me
17:11 < djc> now I have to set project.object_folder, which I'm unsure about
17:26 < djc> using cmake for my project, "mkdir -p build && cd build && cmake .. && make -j 
             {workers}" as the build_command doesn't seem to do the right thing
17:26 < djc> and it seems like {workers} was renamed to {jobs}?
Hi, djc. Can I direct you to the es branch? We're just about to merge it in, and it's beter documented and more capable.

The "dxr" executable is a new feature of the es branch. Make sure you're reading the right version on readthedocs: there's a subtle difference in URL; you can use the "v:" menu at the bottom to switch. On master, as you deduced, it's dxr-build.py and dxr-serve.py.

On the es branch, we've replaced the config system, so you do get nicer error messages now (no tracebacks). target_folder is gone altogether. object_folder now has a sane default (and is better documented).

workers vs. jobs is another es/master thing. On master, it's $job. On es, it's {workers}, though $jobs is still supported for backward compatibility for now.

Sorry you had a hard time; do pop into IRC, and we'll make sure you get sorted out. I'm going to set this to wontfix, just because we're about to pave over it all with the es branch.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.