views:

39

answers:

2

I'm interested in Qooxdoo as a possible web development framework. I have downloaded the SDK and installed it in a central location on my PC as I expect to use it on multiple projects. I used the create-application.py script to make a new test application and added all the generated files to my version control system.

I would like to be able to collaborate on this with other developers on other PCs. They are likely to have the SDK installed in a different location. The auto-generated files in Qooxdoo seem to include the SDK path in both config.json and generator.py: if the SDK path moves, the generator.py script stops working. generator.py doesn't seem to be too much of a problem as it looks in config.json for an updated path, but I'm not sure how best to handle config.json.

The only options I've thought of so far are:

  1. Exclude it from the VCS, but there doesn't seem to be a script to regenerate it automatically, so this could be dangerous.
  2. Add it to the VCS but have each developer modify the path line and accept that it might need to be adjusted whenever changes are merged.
  3. Change config.json to be a path and a single 'include' line that points to a second file that contains all the non-SDK-path related information.
  4. Use a relative path to the SDK and keep a separate, closely located copy of the SDK for every project that uses it.

Approach 1 would be ideal if the generation script existed; approach 2 is really nasty; I couldn't get approach 3 to work and approach 4 is a bit messy as it means multiple copies of the SDK littered about the place.

The Android SDK seems to deal with this very well (using approach 1), with the SDK path in its own file with a script that automatically generates that file. As far as I can tell, Qooxdoo puts lots of other important information in config.json and the only way to automatically generate that file is to create a new project.

Is there a better/recommended way to deal with this?

+3  A: 

We work with a symbolic link pointing to the sdk ... config.json contains just the path of the link.

Tobi Oetiker
That's a good idea. How would this be used for developers on Windows?
NPB
Hmmm, not sure if this works, but http://technet.microsoft.com/en-us/library/cc753194(WS.10).aspx suggests that the mlink command should provide you with symbolic links on windows ntfs filesystems ...
Tobi Oetiker
also note that if you have a samba server you can make the symbolic link there and windows will think there was a local copy of qooxdoo right there.
Tobi Oetiker
+3  A: 

As an alternative to using symlinks, you can override the QOOXDOO_PATH macro on the command line:

./generate.py source -m QOOXDOO_PATH:<local_path_to_qooxdoo>

(Depending on the shell you are using you might have to apply some proper quoting of the -m argument). This way, every programmer can use his locally installed qooxdoo SDK. You can even drop the QOOXDOO_PATH entry from config.json to enforce this.

ThomasH
This sounds almost perfect: I could easily edit the local generator.py script so that the argument is added automatically and the QOOXDOO_PATH is loaded from another python script (with nothing else in it). Unfortunately, it doesn't work on Windows either as the higher level `generator.py` uses `split(':')` rather than `split(':', 1)`, so Windows paths (with a `:` in them after the drive letter get broken up and you get an error message). So close and yet so far...
NPB
This has already been fixed in trunk :-). If you want to stick with the released 1.2, just go ahead and patch tool/pylib/misc/ExtendAction.py:41.
ThomasH
Excellent, many thanks.
NPB