[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