On Fri, May 4, 2012 at 7:14 PM, Chris Lattner <[email protected]> wrote:
> > On May 4, 2012, at 4:27 AM, Hal Finkel wrote: > > >> > >> FWIW, I don't think that this makes sense from a community standpoint. > >> > >> If you're serious about building a fortran frontend (which would be > >> really really cool). I think we should start it as another LLVM > >> subproject. It can certainly build off and use the Clang "liblex" to > >> get the preprocessor etc, and taking changes to support Fortran into > >> the clang tree would be perfectly fine. > > > > Alright cool, let's do that then. Based on the feedback I've received, > > it seems like it makes the most sense to add Fortran support directly > > into the driver and lexer, and keep everything else as a separate > > subproject. This subproject will have its own Parser, Sema, AST, > > CodeGen, etc. subdirectories. > > Sounds good to me. > > > If we set this up kind of like clang is > > setup, then the build system will detect whether there is a fortran > > subdirectory in clang, and if so, will build (defining > > CLANG_HAS_FORTRAN or something like that) and link the extra components. > > Should "flang" (please come up with a better name! :) be in > llvm/tools/flang or in llvm/tools/clang/flang? I think that the former > makes more sense. These are peer projects, even if one is dependent on the > other. > > -Chris > One minor nit: I can certainly understand reusing the lexer/preprocessor if it is nearly identical and the tooling mechanism just added by Manuel because it's a great infrastructure, however on the other hand I am not sure about the driver itself... I don't know Fortran, so perhaps it's obvious to you Hal, but I wonder if perhaps it would make sense to produce a different binary, with its own set of flags ? -- Matthieu
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
