[cmake-developers] daemon-mode meeting last Tuesday

Tobias Hunger tobias.hunger at gmail.com
Fri Jun 24 04:12:08 EDT 2016


Hallo Daniel,

On Fri, Jun 24, 2016 at 9:59 AM, Daniel Pfeifer <daniel at pfeifer-mail.de> wrote:
> On Thu, Jun 23, 2016 at 2:27 PM, Tobias Hunger <Tobias.Hunger at qt.io> wrote:
>>   * We both think it only makes sense to merge the infrastructure part into
>>     cmake (if it passes review first of course) once we have some functionality
>>     that is genuinely useful. So we want to aim at having the infrastructure
>>     and the codemodel merged in one go.
>
> Please think about adding libuv earlier. As Brad wrote before, libuv
> could replace some #ifdef code that we currently have (process
> handling, file operations). I am currently refactoring the code around
> the cmOutputConverter and I would like to introduce a cmPath class (I
> will write more about that later, but I can already say that libuv
> might come handy for some functionality).

Feel free to merge it at your own pace. I'll just use your copy then:-)

Currently I just link to an external version of said library and have
not yet tried to figure out what the policy is wrt. 3rd party code in
cmake. Stephen suggested that we would need to include a copy into the
cmake repository and hinted at a script that keeps these copies
updated.

>>   2.7 cache (report contents of CMakeCache.txt file)
>>
>>   * Review by other potential users would be appreciated, but no obvious
>>     problems seen.
>
> Is this needed? If the CMakeCache.txt file continues to be written,
> clients could just parse that file. If clients want to make changes
> (ie. cache editors), they can rewrite the file. Is that a problem? I
> assume it is, because CMake needs to reconfigure when it rereads it.
> In that case, the server should provide a way to report the contents,
> but also ways to modify it.

Yes, this is needed.

I do not want 3rd party code to interact with what is basically a file
internal to cmake.

And the syntax of that file is not as trivial as the comment at its
top claims it is. Just check how properties on values are encoded.

Best Regards,
Tobias


More information about the cmake-developers mailing list