7

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?

NPB
  • 115
  • 1
  • 4
  • I'm not really getting 3. Can you elaborate? – ThomasH Sep 28 '10 at 12:31
  • In config.json there's a section "include", so took a flier (not knowing anything about json) and copied the whole file except the QOOXDOO path into another file and referenced the other file in the include section. It didn't work. – NPB Sep 28 '10 at 14:37

2 Answers2

6

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
  • 22,276
  • 13
  • 61
  • 62
  • 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 Sep 28 '10 at 14:39
  • 1
    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 Sep 28 '10 at 15:59
4

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

Tobi Oetiker
  • 5,167
  • 2
  • 17
  • 23
  • That's a good idea. How would this be used for developers on Windows? – NPB Sep 28 '10 at 09:38
  • 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 Oct 02 '10 at 05:36
  • 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 Oct 02 '10 at 05:37