[cmake-developers] Using a custom DSL compiler in CMake

Chris Bieneman chris.bieneman at me.com
Tue Jun 21 19:31:55 EDT 2016


Brad,

Thanks for the detailed response. This all makes a lot of sense. I’ll have to stew on this a bit and see where it leads me. In general it sounds to me like there is no easy solution here.

Thanks,
-Chris

> On Jun 21, 2016, at 1:05 PM, Brad King <brad.king at kitware.com> wrote:
> 
> On 06/21/2016 02:18 PM, Chris Bieneman wrote:
>> Our current solution to work with this tool in CMake
> 
> For reference, a quick look at LLVM's `cmake/modules/TableGen.cmake`
> indicates that the current solution is based on add_custom_command.
> 
>> The harder part is that our DSL supports C-like includes.
> 
> The add_custom_command signature has an IMPLICIT_DEPENDS option
> for this, but it only works for Makefile generators.
> 
>> Our DSL compiler can generate .d files, but hooking that up to
>> CMake is a harder problem.
> 
> With some work it may be possible to teach our Ninja generator how
> to consume .d files in custom commands.  Perhaps such support could
> even be extended to the Makefile generators instead of using our
> approximate scanning implementation.
> 
> In general implicit dependencies cannot be cleanly supported by
> the Visual Studio or Xcode generators.  Those environments provide
> no hooks for custom build-time dependency scanning.  At best one
> can have the custom command produce a file as a side effect that
> can be consumed by CMake on the next run.  This would work for
> all generators but causes lots of CMake re-runs.
> 
>> My thought was to try and treat TableGen as a language.
>> There are some complications with that because we don’t
>> actually have a compiler for it at configuration time.
> 
> I don't think that is a good approach both because we won't
> be able to enable the language without the compiler already
> existing and because custom languages do not work well in
> the IDE generators (and will have the same dependency scanning
> problems as above).  See above approaches instead.
> 
> -Brad
> 



More information about the cmake-developers mailing list