Hi Eric Sunshine wrote: > - It may not necessarily be true that breaking the bindings apart > into smaller modules would improve build time (in fact, it might > lengthen it). > > - Breaking the bindings apart into smaller modules, although not > necessarily improving overall build time, might improve the > "perceived build time". Watching twelve files build at twenty seconds > each is perhaps perceptually more acceptable than waiting four > minutes for a single file to build. > Well, as commented by other posts in this thread thing is problem is more the ram needed to compile than processing power. If ram fills up compile time is incredibly longer. That said, it is very possible that compilation will take a bit longer for the current best cases (where the bindings get compiled in appropriate time), as it will have to handle a bit more code, but still as you say this can affect perceived build time positively :)
So problems to address by this splitting: - Too much memory required. - Too many symbols for some linkers so they cant link the final thing - Some system configs takes ages linking, not sure whats the problem here, but isn't a memory problem (cpu stays at 100% for loong time, no memory swapping). > - Breaking the bindings apart into smaller modules will almost > certainly resolve the linking problems on various platforms. For this > reason alone, such a change should be considered. > > - As a rough heuristic, I might suggest creating one binding module > per top-level CS header directory. For instance, csutil, csgeom, > iutil, iengine, ivaria, etc. This won't be a perfectly balanced break- > down, however, it is important to factor the "ifoo" stuff into the > equation since the SCF interfaces account for a significant portion > of the bulk of the Swig-generated code. > > Yes this is fine, only thing i have to see is whether dependencies among modules would allow doing the simple approach, or whether some base module or modules will be needed (i am not 100% sure but current cspace.i file has includes in strange order, whether it is required is something we have to see). > It is important to do this in a way which does not penalize end- > users. The breaking-apart of the bindings should be an > "implementation detail" invisible (or at least not obvious) to > clients. The above approach should work admirably for Python. Perl > also can handle this sort of thing easily with a little hand-written > (or perhaps auto-generated) Perl glue code which brings all the > modules together. Lua, too, I believe can be made to manage this in > much the same way with a small amount of glue code. Java might > require some extra effort, possibly in the form of 'importing' the > various sub-packages into the top-level 'org.crystalspace3d' package. > > Agreed. This is one of the reasons i started this thread, to do this effectively i'd need someone who can test the new binding structure and adapt respective jamfiles for other languages than python (at least java and perl so as to not break those) once i can start work. >> Then also there is a detail that could be attacked at the same time, >> right now cspython links in the _cspace swig generated library, also >> cel's blcelc is linking in _cspace and _blcelc libraries. This is >> convenient for distribution but i'm not sure about whether its best >> approach, in any case i'd like to know if other languages are doing >> similar or they use the swig generated dlls. (in python the dlls are >> only used from pure python apps, if using embedded code the versions >> linked in are used instead). >> > > This is an approach which needs to be applied to the Perl bindings > and to the Lua bindings (whenever Lua is added ultimately to the > project). Presently, the Perl Jamfile plays around with the low-level > object file list when building the Perl CS plugin and stand-alone > Perl module. This is ugly. The "library" approach is much cleaner and > superior in my opinion. > > Sorry, I think i didn't describe the actual problem appropriately. The problem is just that blpython includes both _cspace.so and _blcelc.so by initing those modules internally. Both python module dlls get linked in the plugins (cspython.so and blpython.so). In the new situation to get the same result, we'd have to link in all the modules dlls (_csutil.so, _cstool.so...). It is not clear to me whether this is the best approach as it seems to me linking all the new modules into these plugins will get us back to the linking problems, so maybe this approach of linking in the language specific module dll into the cs plugin has to be discarded, and instead depend on distributing the python modules also, ie the cspace/ folder i was talking about before with all .py and .dll files (and same for other language plugins if they're doing this possibly). Pablo ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[EMAIL PROTECTED]
