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.

other minor things (cmDependsD not working for older compilers last I

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

Reply via email to