You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that we no longer pass around classpaths, and now that scripts update CLASSPATH to include the JARs from jackson, maybe we should just have plcc copy over ParseJsonAst.java by default and drop its --json_ast flag. This would simplify plcc in general, and specifically simplifies the process to generate an AST.
The disadvantage of this issue's suggestion is that if one wants to manually compile Java/*, they would need to include the JARs from jackson in their CLASSPATH. If we agree that using plccmk to compile would be more common, then we could add a --no_ast option to plcc to prevent copying ParseJsonAst.java, and thus avoid requiring adding jackson's JARs to the CLASSPATH when compiling manually.
The text was updated successfully, but these errors were encountered:
Now that we no longer pass around classpaths, and now that scripts update CLASSPATH to include the JARs from jackson, maybe we should just have plcc copy over ParseJsonAst.java by default and drop its --json_ast flag. This would simplify plcc in general, and specifically simplifies the process to generate an AST.
Currently, to produce an AST
$ plccmk --json_ast lang.plcc $ plcc --json_ast < prog.lang
With this issue's suggestion...
$ plccmk lang.plcc $ parse --json_ast < prog.lang
With this issue and #123 ...
$ plccmk lang.plcc $ ast < prog.lang
The disadvantage of this issue's suggestion is that if one wants to manually compile Java/*, they would need to include the JARs from jackson in their CLASSPATH. If we agree that using plccmk to compile would be more common, then we could add a --no_ast option to plcc to prevent copying ParseJsonAst.java, and thus avoid requiring adding jackson's JARs to the CLASSPATH when compiling manually.
The text was updated successfully, but these errors were encountered: