On Mon, 7 Oct 2002, Dalibor Topic wrote: > That means we'd have to operate on bytecode level. > There are many toolkits for such projects. I believe > that's preferable to writing a java parser and doing a > source-to-source translation on all java library > source code.
Admittedly the preprocessor approach does have its disadvantages. However, how do you do conditional specification on bytecode level, especially with optimization? I guess you could just specify that optimization always happens after the conditional selection. I still remain somewhat suspicious; this toolkit would likely need to be able to generate alternative code etc. and certainly preprocessors for source-code are much more common/available than bytecode managers. I'm not sure what you mean by "java parser", there's no need for a preprocessor to parse Java itself (Think C pre-processor;), just simple preprocessor directives. Overall how it is done doesn't matter to me so much, I'd just like to see it done, I understand some people may prefer C styel pre-processing because that's what they're familiar, others probably would be totally opposed to it just ebcause it's C and not Java. In fact, it should be possible to use a standard C pre-processor to parse basic preprocessor directvies for Java, altough preferably it should be as well integrated with the compiler/tools as possible. Note that for tet pre-processor style solution its still somewhat possible to use an XML database to specify what segments are used in each profile instead of specifying every profile related to a given segment in the source-code. I'm also personally partial to the straight & simple "wysiwyg" approach in this, without needing to compile, run a processor and then disassemble/whatever to determine if the combination of the XML rules and source is what you want. (Admittedly there are cases where preprocessing directives in source-code aren't as clear-cut either, but by far it tends to be clearer in intent and interpetation). But, well, if we get an usable XML-database based bytecode post-processing tool that is intuitive and easy to use, I won't complain, but neither do I volunteer to build one ;) As for text pre-processing, we could use Cpp, but I'd much rather have something that looks Java-like, is designed for it and preferably constructs usable programs even without preprocessor. -Jukka Santala _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
