[cfe-commits] [RFC and PATCH] Fortran
matthieu.monrocq at gmail.com
Fri May 4 10:21:03 PDT 2012
On Fri, May 4, 2012 at 7:14 PM, Chris Lattner <clattner at apple.com> 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
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 ?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits