[cfe-dev] Using clang as a meta-data generator.

[chris nuernberger]

Yep, that is cool; I have been completely successful with what I
wanted to do and am really excited to start working with clang much
more.  C++ has needed a good, free frontend for a very long time (like
since it was ever conceived of) so you could auto-generate meta data
about your system.  Clang is an excellently design system that really
feels solid to work with.

To seal this thread off with some answers for anyone else going the
same route....

To compile as much MS stuff as possible you need to use
-fms-extensions and -D_DEBUG -DWIN32 -nobuiltininc (for debug).

It was actually easier to copy cc1_main.cpp to my own project and
build my own executable reusing most of the code but hardcoding my own
action into the system.  This is because:

LLVM doesn't build correctly into dlls (shared objects) on a windows system.
Thus clang doesn't build correctly into dlls on a windows system.
Thus writing a shared object plugin for clang isn't a possibility on windows.

Thus the easiest thing to do was to write an adjunct clang!  It is
easier for my users, anyway, as they don't need to know more command
line options than absolutely necessary.

I noticed a couple thing about clang that I wanted to talk about.

1.  The objects in the AST have too many responsibilities.  I
understand why this is but I think it is not that clean.  Printing and
dumping, in my opinion, should be completely handled outside of the
AST hierarchy for several reasons.  The first is to avoid mixing
responsibilities and code bloat.  Most of the AST objects do more than
one thing (although probably only one thing well).  The second is to
ensure that someone coming along *could* write these routines as
plugins; it would orient those objects more towards being libraries
and less towards being end-all-be-all objects.

2.  The clang macro for add_executable doesn't handle lists of files.
Thus if you use a glob routine to automatically add all the files in a
directory clang_add_executable won't work.  To make this work the
cmake list object would need a flatten function; to do this you would
need a test to know if each object in the list was in fact another
list or just a single string name.  I couldn't figure out how to do
this else I would have just posted my solution.

3.  There really isn't an automatic plugin facility for clang in the
sense of put your directory, cmakelists.txt and files here and the
build process will automatically pick it up.  I added this to the
clang system but I am unsure as to where to submit a patch.  I added a
plugin directory and then also added a special CMakeLists.txt to that
directory that simple scans for subdirectories and adds every one,
ignoring ones that start with period and the cmake-created CMakeFiles
directory.  That CMakeLists.txt is attached.

Hope this feedback helps!  I am really impressed and excited about the
possibilities that clang enables!

Chris
-------------- next part --------------
macro(list_subdirectories retval curdir return_relative)
  file(GLOB sub-dir RELATIVE ${curdir} *)
  set(list_of_dirs "")
  foreach(dir ${sub-dir})
    if(IS_DIRECTORY ${curdir}/${dir} AND NOT (${dir} MATCHES "CMakeFiles|[.].*") )
      if (${return_relative})
        set(list_of_dirs ${list_of_dirs} ${dir})
      else()
        set(list_of_dirs ${list_of_dirs} ${curdir}/${dir})
      endif()
    endif()
  endforeach()
  set(${retval} ${list_of_dirs})
endmacro()



list_subdirectories(plugins ${CMAKE_CURRENT_SOURCE_DIR} 1)

foreach(dir ${plugins})
  add_subdirectory(${dir})
endforeach()