> time to set it every time I want to make small modifications. As I said, I > think the basic architecture is fine, no need to change that, but the > whole > overriding and extending stuff is completely arcane and bugged. This > should > be simplified, and the documentation should also be straightlined. That > would be really useful.
So what should we do? I mean, I don't expect a polished answer, a finished design or something. But beyond the "simple things should be simple", what would qualify for you to be appropriate? Maybe you could give a few lines of pseudo code that express what a potential job should do, together with a bit of explanation about the semantics of the used constructs. - Should we maintain a proprietary build system at all, or should we switch to an existing solution like scons or paver? Do you like their model better? To pick up on one specific point you mention, we could probably put away with overriding and extending. That would mean, each configuration needs to carry all necessary information with it, as it cannot make references to information outside of it. It'd need to contain information to create source and build versions of the app, as well as produce Apiviewer and Testrunner instances, run 'lint' and 'fix' jobs, create combined images and dependency graphs, extract translatable strings and migrate source code, and so forth. As it stands, such a config file, even for the simplest GUI skeleton, would comprise around 1,200 lines of config code. But since there was no form of code reuse (so no "common" job holding shared settings), even within a single config file you would have to repeat a lot of common information within the various jobs, so I would guess you end up with around 2,000 LOC config code for a single file. And this is just for one skeleton. As we currently maintain 4 of them, that makes 8,000 LOC config code you have to maintain. On top of that come the config files for our standard apps and components, let's say a defensive 7, which would amount to another 14,000 LOC config code, together roughly 22,000 lines of code to maintain. Every general change or addition had to applied to all of them, potentially multiple times... I was recently working on a big qooxdoo project with, let's say, around 600 qooxdoo classes. The code base was to support 4 individual products that were generated from it (and this number is supposed to increase), each coming with its own 1-4 qooxdoo themes. The configuration of this project (not including the basic config files that are included from our framework) was spread over roughly 7 individual files, together probably a few thousand lines of config code. There is very little repetition among them, if any, otherwise this number would be much larger. And I don't know how I could have managed this without the overriding and extending facilities of the config system. I understand your frustration with the build system, but I think it will not be easy to come up with alternatives that will provide equal power with a more approachable user model. But I'm really interested to hear suggestions. Maybe there should be a second layer around the basic system, a "light" version, I don't know. Some suggested to restrict user configuration to "let" macros only. We had this in 0.7, providing some 60+ macros for user configuration. I thought extending jobs would be more appropriate for people with an OO background, but maybe I'm wrong. T. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
