gmane.comp.lang.javascript.qooxdoo.devel

Path to Qx lib in 0.8 (config.json & generate.py issue)

Here is one regression in 0.8: moving the qooxdoo lib around is a pain:

In 0.7.x you only had to change the path to where Qooxdoo is installed
in one place. Now you have to change it in 3 places: twice in
config.json and one in generate.py, which is especially ugly IMO.

This is problematic for writing installation instructions of my App (I
can't force people to install qooxdoo in the exact same folder as I
did).

Couldn't the "userland" generate.py get the path to qooxdoo from config.json?
Also I tried to eliminate the extra one in config.json, by having
something like this:

  "let" :
  {
    "QOOXDOO_ROOT" : "../qooxdoo/0.8/",
    "QOOXDOO_PATH" : "${QOOXDOO_ROOT}/framework",
  },

  "include" :
  [
    {
      "path" : "${QOOXDOO_ROOT}/tool/data/config/application.json",
      "as"   : "appconf"
    }
  ],

But apparently the macro system doesn't work for the "path" key (it's
not expanded)...

(Continue reading)

headers

Fabian Jakobs | 8 Oct 10:14

Re: Path to Qx lib in 0.8 (config.json & generate.py issue)

Gaetan de Menten schrieb:
> Here is one regression in 0.8: moving the qooxdoo lib around is a pain:
>
> In 0.7.x you only had to change the path to where Qooxdoo is installed
> in one place. Now you have to change it in 3 places: twice in
> config.json and one in generate.py, which is especially ugly IMO.
>
> This is problematic for writing installation instructions of my App (I
> can't force people to install qooxdoo in the exact same folder as I
> did).
>
> Couldn't the "userland" generate.py get the path to qooxdoo from config.json?
> Also I tried to eliminate the extra one in config.json, by having
> something like this:
>
>   "let" :
>   {
>     "QOOXDOO_ROOT" : "../qooxdoo/0.8/",
>     "QOOXDOO_PATH" : "${QOOXDOO_ROOT}/framework",
>   },
>
>   "include" :
>   [
>     {
>       "path" : "${QOOXDOO_ROOT}/tool/data/config/application.json",
>       "as"   : "appconf"
>     }
>   ],
>
> But apparently the macro system doesn't work for the "path" key (it's

(Continue reading)

headers

Gaetan de Menten | 8 Oct 10:57

Re: Path to Qx lib in 0.8 (config.json & generate.py issue)

On Wed, Oct 8, 2008 at 10:14 AM, Fabian Jakobs <fabian.jakobs <at> 1und1.de> wrote:
> Gaetan de Menten schrieb:
>> Here is one regression in 0.8: moving the qooxdoo lib around is a pain:
>>
>> In 0.7.x you only had to change the path to where Qooxdoo is installed
>> in one place. Now you have to change it in 3 places: twice in
>> config.json and one in generate.py, which is especially ugly IMO.
>
> I think this is a good point. Could you open a bug for this?

Done.
http://bugzilla.qooxdoo.org/show_bug.cgi?id=1456

--

-- 
Gaëtan de Menten
http://openhex.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

thron7 | 8 Oct 16:40

Re: Path to Qx lib in 0.8 (config.json & generate.py issue)

Gaetan de Menten wrote:
> Here is one regression in 0.8: moving the qooxdoo lib around is a pain:
>
> In 0.7.x you only had to change the path to where Qooxdoo is installed
> in one place. Now you have to change it in 3 places: twice in
> config.json and one in generate.py, which is especially ugly IMO.
>   

Yes, but the generate.py is only a concession to people which are 
uncomfortable with juggling paths, for the time being. It's just a path 
proxy for tool/bin/generator.py. I wouldn't use it altogether but just 
added ${QX}/tool/bin to my PATH, or define a shell alias to it :).

> Couldn't the "userland" generate.py get the path to qooxdoo from config.json?
>   

That would be possible, but actually we are aspiring to something more 
elaborate, like a build tool gui.

> Also I tried to eliminate the extra one in config.json, by having
> something like this:
>
>   "let" :
>   {
>     "QOOXDOO_ROOT" : "../qooxdoo/0.8/",
>     "QOOXDOO_PATH" : "${QOOXDOO_ROOT}/framework",
>   },
>
>   "include" :

(Continue reading)