Re: WIP: About CMake v2
От | Yury Zhuravlev |
---|---|
Тема | Re: WIP: About CMake v2 |
Дата | |
Msg-id | 6cd3400f-a1bd-40ac-b2c9-e7e221f548eb@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: WIP: About CMake v2 (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: WIP: About CMake v2
(Craig Ringer <craig.ringer@2ndquadrant.com>)
|
Список | pgsql-hackers |
Hello. Peter Eisentraut wrote: > I tried this out. Because of some file moves in initdb and > pg_basebackup, the build fails: Yes, I need rebase patch to latest master. I do it as soon as possible. Also I have some new achievements. >I suggest you use git format-patch to produce patches. This is easier >to apply, especially when there are a lot of new files involved. Also >use the git facilities to check for whitespace errors. I agree. >I suggest for now you could put this into a README.cmake file in your >patch. We don't need to commit it that way, but it would help in the >meantime. Good idea, currently I write all documentation on github. I will try to move it to patch. >When I run cmake without options, it seems to do opportunistic feature >checking. For example, it turns on OpenSSL or Python support if it can >find it, otherwise it turns it off. We need this to be deterministic. >Without options, choose the basic feature set, require all other >features to be turned on explicitly, fail if they can't be found. >Whatever the Autoconf-based build does now has been fairly deliberately >tuned, so there should be very little reason to deviate from that. This approach I see only in Postgres project and not fully understood. Can you explain me more what reasons led to this approach? Not big deal to make behavior like postgres Autoconf but I think it's important clear view here. >The Python check appears to be picking up pieces from two different >Python installations: Ooops you right. For Python detecting I use standard CMake module and his behavior depending on CMake version. We should really careful here. >The check results otherwise look OK, but I'm a bit confused about the >order. It checks for some functions before all the header files are >checked for. Is that intentional? I have plans to change order checks. >There are a number of changes in .[ch] and .pl files that are unclear >and not explained. Please explain them. You can also submit separate >preliminary patches if you need to do some refactoring. Ultimately, I >would expect this patch not to require C code changes. I suppose separate patches with comments will be best way. I will do it. I think we can talks about details after that. Big thanks for your remarks it's very important for me and this "small" project. I will try to do all tasks quickly. Best regards. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: