Ah, not so simple then :) I might try it out in a few months if work slacks off, thanks for the info.
john On 14/09/2010 10:16, "thron7" <[email protected]> wrote: > > >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 ------------------------------------------------------------------------------ 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
