On Wednesday, 2 April 2014 at 03:34:14 UTC, Ben Boeckel wrote:
However, I would like to get this to the CMake list sometime
soon
(within a month?) for feedback before too many start using it
externally
(especially since getting it on the radar for 3.1 would be
nice).
I can probably manage that. I'd also rather it go through CMake
vetting before HN/reddit vetting, as I feel like the former would
be a lot more productive than the latter.
For example, it seems that there are new signatures that need
vetting
(include_directories(TEXT)), some new INTERFACE properties
which need
plumbed (text include directories at least, possibly DDoc
stuff?),
My understanding of INTERFACE properties is that they are used
when dealing with importing/exporting targets. If this is the
case, I'm not sure of a case when text includes would need to be
provided through this. Text imports work at compile time,
literally putting a string of the contents of the specified file
where the import() was.
and
other minor things (cmDependsD not working for older compilers
last I
looked,
Yeah, I'm not sure there's much I can do about that. I have to
choose between scanning textually imported files as dependencies
(which they are) or supporting older compilers. Granted, the
Ninja dependency resolution doesn't register text imports, since
I have to specify the filename in the arguments. "-deps >
<DEPFILE>" could work, but we would have to ensure that it comes
last on the command line. "-deps=<DEPFILE>" doesn't output all
the same information as "-deps > <DEPFILE>". Same holds for GDC
and LDC equivalents.
- Trent
