From: Kevin B. <jyt...@sa...> - 2003-07-31 04:13:56
|
Jython's CVS archive includes the JavaCC output files, so we can build it without JavaCC. However, 'ant clean' removes these files, so I keep having to get them out of CVS again. I'd like to modify 'ant clean' to not delete those files, but add a target 'ant distclean' that would remove them. 'all' will continue to call 'clean' rather than 'distclean'. Thoughts? kb Here are clean & distclean targets I'd suggest: <target name="clean" depends="init"> <delete dir="${outputDir}/" /> <delete> <fileset dir="${distDir}" excludes="jython.jar"/> </delete> <property name="parser" value="${sourceDir}/org/python/parser" /> <delete file="${parser}/python.jj"/> <delete file="${parser}/ASCII_CharStream.java"/> </target> <target name="distclean" depends="clean"> <delete file="${parser}/PythonGrammar.java" /> <delete file="${parser}/PythonGrammarConstants.java" /> <delete file="${parser}/PythonGrammarTokenManager.java" /> <delete file="${parser}/PythonGrammarTreeConstants.java" /> <delete file="${parser}/Token.java" /> </target> |
From: Samuele P. <ped...@bl...> - 2003-07-31 05:03:13
|
At 22:13 30.07.2003 -0600, Kevin Butler wrote: >Jython's CVS archive includes the JavaCC output files, so we can build it >without JavaCC. > >However, 'ant clean' removes these files, so I keep having to get them out >of CVS again. > >I'd like to modify 'ant clean' to not delete those files, but add a target >'ant distclean' that would remove them. > >'all' will continue to call 'clean' rather than 'distclean'. > >Thoughts? > >kb > >Here are clean & distclean targets I'd suggest: > > <target name="clean" depends="init"> > <delete dir="${outputDir}/" /> > <delete> > <fileset dir="${distDir}" excludes="jython.jar"/> > </delete> > <property name="parser" value="${sourceDir}/org/python/parser" /> > <delete file="${parser}/python.jj"/> > <delete file="${parser}/ASCII_CharStream.java"/> > </target> > > <target name="distclean" depends="clean"> > <delete file="${parser}/PythonGrammar.java" /> > <delete file="${parser}/PythonGrammarConstants.java" /> > <delete file="${parser}/PythonGrammarTokenManager.java" /> > <delete file="${parser}/PythonGrammarTreeConstants.java" /> > <delete file="${parser}/Token.java" /> > </target> I think the real problem is that there is no point in forcing the recreation of files that live in the CVS in the first place. The parser compilation logic also depends on keeping around python.jj which does not live in the CVS. At the momement under Eclipse I'm using this seperate build.xml to deal with the parser (re)generation: <project name="jython-parser" default="parser" basedir="." > <property name="javacc" value="/usr/local/javacc" /> <target name="pre"> <uptodate property="parser.regen.notreq" targetfile="${basedir}/PythonGrammarConstants.java"> <srcfiles dir="${basedir}" includes="python.jjt" /> </uptodate> </target> <target name="clean" unless="parser.regen.notreq"> <delete file="${basedir}/PythonGrammar.java" /> <delete file="${basedir}/PythonGrammarTreeConstants.java" /> <delete file="${basedir}/PythonGrammarTokenManager.java" /> <delete file="${basedir}/PythonGrammarConstants.java" /> <delete file="${basedir}/CharStream.java" /> </target> <target name="tree" unless="parser.regen.notreq"> <java classname="jjtree" classpath="${javacc}/bin/lib/javacc.jar" fork="yes" > <arg value="-OUTPUT_DIRECTORY=${basedir}" /> <arg file="${basedir}/python.jjt" /> </java> </target> <target name="gen" unless="parser.regen.notreq" depends="tree" > <java classname="javacc" classpath="${javacc}/bin/lib/javacc.jar" fork="yes" > <arg value="-OUTPUT_DIRECTORY=${basedir}" /> <arg file="${basedir}/python.jj" /> </java> <delete file="${basedir}/python.jj" /> </target> <target name="parser" depends="pre,clean,gen" /> </project> this should be integrated back with the main build.xml, or called from it. I planned to do that but I haven't sofar. Notice that ASCII_CharStream.java is now CharStream.java. regards. |
From: Samuele P. <ped...@bl...> - 2003-07-31 06:33:15
|
Hi. I have noticed that there is some code duplication in javashell impl. LazyDict is implemented both in javashell.py and LazyDict.py. To be honest I would keep the version in javashell.py, I don't see the point in polluting the global Lib modules namespace unless strictly necessary or with files beginning in j(ava)..., because we share it with CPython. Testing code for javashell.py is both in javashell.py and test/test_javashell.py. test_javashell.py produces output even in case of success, I think pyunit tests should be basically silent if all is fine. Can you fix these small things? Thanks. |
From: Kevin B. <jyt...@sa...> - 2003-07-31 09:24:09
|
Samuele Pedroni wrote: > Hi. > > I have noticed that there is some code duplication in javashell impl. Hadn't completed the refactoring... > LazyDict is implemented both in javashell.py and LazyDict.py. To be > honest I would keep the version in javashell.py, I don't see the point > in polluting the global Lib modules namespace unless strictly > necessary or with files beginning in j(ava)..., because we share it > with CPython. The reason for a standalone LazyDict is so that javaos can avoid importing javashell (expensive) until it is needed. Though I'm also uncomfortable adding modules arbitrarily... Converted into a circular dependency (ick) between javaos & javashell, leveraging Python's import-once model. > Testing code for javashell.py is both in javashell.py and > test/test_javashell.py. Actually had just fixed that. :-) > test_javashell.py produces output even in case of success, I think > pyunit tests should be basically silent if all is fine. Agreed. > Can you fix these small things? Done. kb |
From: Samuele P. <ped...@bl...> - 2003-07-31 07:04:09
|
At 06:58 31.07.2003 +0200, Samuele Pedroni wrote: >this should be integrated back with the main build.xml, or called from it. >I planned to do that but I haven't sofar. > Done, check whether the changes work for you. Thanks. |
From: Kevin J. B. <jyt...@sa...> - 2003-08-01 18:13:41
|
Samuele Pedroni wrote: > At 06:58 31.07.2003 +0200, Samuele Pedroni wrote: > >> this should be integrated back with the main build.xml, or called >> from it. I planned to do that but I haven't sofar. > > Done, check whether the changes work for you. Looks good. 'ant clean all' now succeeds w/o javacc and w/o re-checking out those files. kb |