On 09/14/2010 10:06 AM, John Spackman wrote: > Hi Thomas, > > Brill, that sounds exactly like it. I can't quite tell though - does the > generator "source-hybrid" work yet?
Nope, not implemented yet. > I.e. The bug's still open because > there's some assembly required? Yes, quite. For one, the desired "source" build (basically a 'cat' of the source files into a single one) is currently not supported by the generator. I want to extend this idea so that you can have any set of classes that goes into a build at any level of optimization. Then there is the issue of packaging, so that sets of classes go into a common package, the single class staying in its source file being an extreme of that. You need configuration support for that. The current "packages" key does not provide means to determine exactly which classes go together in a common package, and is rather driven by concerns of load order than by which package remains stable and which might change. The third issue is that of "linking". The generator is currently not prepared to include packages in a build run that stem from a previous run, and are pre-built in that sense. You could re-create the "stable" packages every time you run a build, but I think this would be missing at least some of the point. Also, there are other scenarios where including pre-built packages would be interesting, so I think this should be solved in general. But this also raises the question what the generator needs to know about a pre-built package, what it can infer from the config or the file itself (e.g. the list of contained classes). And so forth and so on :). T. > > Thanks > John > > On 14/09/2010 08:25, "thron7" <[email protected]> wrote: > >> >> >> On 09/14/2010 08:29 AM, John Spackman wrote: >>> Hi all, >>> >>> Re: "One big build file" - when you develop on a local disk, this is >>> much >>> less relevant than when you use a web server backend. There are over >>> 400 >>> files in an average application and each one causes a request to the >>> server; if I refresh the app I'm working on now there are 474 requests, >>> 99% of which are "304 not modified" responses. >>> >>> This adds up to 15 seconds of network comms for source builds, and is >>> frustrating - in this case it would be much better to have all Qx >>> scripts >>> as a single or a few files (ideally defined by config.json). >> >> What you want is http://bugzilla.qooxdoo.org/show_bug.cgi?id=2008, >> but mind that this is *not* the same as working with a tools-free >> version of qooxdoo. >> >> T. >> >> -------------------------------------------------------------------------- >> ---- >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
