Closed cboulanger closed 5 years ago
as Qooxdoo is a special case as libraries go, it would be appropriate to not list it in the libraries
key at all; this would make it simple to swap qooxdoo repos, but is dependent on being able to reliably locate qooxdoo when not explicitly set (ie with --qxpath
).
What would be really useful would be to persist data in a central location (eg ~/.qooxdoo/
); configuration data could be in a json file in there, and could include things like the default or last used qooxdoo location.
This would be especially useful for sharing projects because the qooxdoo path is the one thing that always needs to be edited to suit local installations. Because qx
supports automatic location and download of contribs, the qooxdoo path is the one remaining thing which is not cross platform.
BTW, does qx
support downloading missing contribs, eg like npm install
downloads modules listed in package.json
?
@johnspackman Re: missing contribs, yes, you just do qx contrib install
and it will download the contribs listed in contrib.json.
We have a global qooxdoo path in the npm_modules path. The problem is that this path differs from installation to installation. What's about adjusting this path during compilation?
not longer needed in new compiler. use qx config qx.library instead
In some cases, you'll need to use a path to the qooxdoo framework that is different from the one given in
compile.json
. For example, if you have the qooxdoo framework in../qooxdoo/framework
in your (committed)compile.json
, but in your Travis CItravis.yml
script, you need./qooxdoo/framework
. A--qxpath/-q
option would allow to set this at runtime.