(0029917)
David Cole (manager)
2012-07-05 13:39

Can anyone verify whether this works on Windows and/or Mac and/or other non-Linux platforms?

Thanks.

(0029918)
Orion Poplawski (reporter)
2012-07-05 14:18

I don't have access to Windows or Mac devel machines.

I did have to change SEND_ERROR to WARNING in the fail_if() macro to get tests to complete when postgresql was not installed.

(0029923)
Rolf Eike Beer (developer)
2012-07-05 17:11

What happens when cross-compiling? Opening and parsing a header file would still work, executing pg-config will surely fail. It's not that I'm generally against that change, that just another problem I see. I would not object a patch that would also look in the *_$arch.h file also if there is a good way to find out what $arch actually is (is it x86_64 or amd64 or ...?). Or just try any method until one works.

David, can you try to get stuff like this installed on one of the Windows test machiches so these find modules can actually be tested on Windows? I fear most of them will horribly break once someone is actually brave enough to test.

(0029924)
Orion Poplawski (reporter)
2012-07-05 17:22

Another possible approach would be to run "#include <pg_config.h>" through the preprocessor and parse the output.

(0029925)
Rolf Eike Beer (developer)
2012-07-05 18:20

CMake doesn't search for the preprocessor (yet).

(0029927)
David Cole (manager)
2012-07-06 07:10

But a similar alternative might be to try_compile a very simple program that includes the header, and analyze the output for values, similar to the way we identify C and C++ compilers. That would even work on cross-compile situations (assuming you can analyze the output without actually running it...)

(0030795)
Brad King (manager)
2012-08-30 10:33

I think a middle-ground approach is to run pg_config if it is available and otherwise fall back to parsing the header. Any multiarch install should provide pg_config and any non-multiarch install (e.g. on Windows) should not have a forwarding header.

(0031154)
Orion Poplawski (reporter)
2012-10-02 17:55

Any chance this could make it into 2.8.10?

(0031159)
David Cole (manager)
2012-10-03 07:58

Probably not a high chance of this getting into 2.8.10 without an active maintainer... This issue is not on the roadmap (no "Target Version" is set), so it has not been on anybody's active radar other than the discussion seen here in the notes (and maybe some discussion on the mailing list? (not sure))

This module needs a maintainer, and somebody who can test it out on all the various platforms.

Once a patch is deemed acceptable (this one still needs some work, see the previous notes) then it needs a maintainer to:

- push a topic branch to the stage
- merge it to 'next'
- follow up on any dashboard errors or test failures for the next day (or more, until the failures are cleared up)
- be available to address any issues that arise with the new code as it hits the real world in the release that follows

(0032164)
Orion Poplawski (reporter)
2013-01-24 23:44

FWIW - here's an updated version of what we're currently using in Fedora.

(0042081)
Kitware Robot (administrator)
2016-06-10 14:28

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Notes
(0029917) David Cole (manager) 2012-07-05 13:39	Can anyone verify whether this works on Windows and/or Mac and/or other non-Linux platforms? Thanks.

(0029918) Orion Poplawski (reporter) 2012-07-05 14:18	I don't have access to Windows or Mac devel machines. I did have to change SEND_ERROR to WARNING in the fail_if() macro to get tests to complete when postgresql was not installed.

(0029923) Rolf Eike Beer (developer) 2012-07-05 17:11	What happens when cross-compiling? Opening and parsing a header file would still work, executing pg-config will surely fail. It's not that I'm generally against that change, that just another problem I see. I would not object a patch that would also look in the *_$arch.h file also if there is a good way to find out what $arch actually is (is it x86_64 or amd64 or ...?). Or just try any method until one works. David, can you try to get stuff like this installed on one of the Windows test machiches so these find modules can actually be tested on Windows? I fear most of them will horribly break once someone is actually brave enough to test.

(0029924) Orion Poplawski (reporter) 2012-07-05 17:22	Another possible approach would be to run "#include <pg_config.h>" through the preprocessor and parse the output.

(0029925) Rolf Eike Beer (developer) 2012-07-05 18:20	CMake doesn't search for the preprocessor (yet).

(0029927) David Cole (manager) 2012-07-06 07:10	But a similar alternative might be to try_compile a very simple program that includes the header, and analyze the output for values, similar to the way we identify C and C++ compilers. That would even work on cross-compile situations (assuming you can analyze the output without actually running it...)

(0030795) Brad King (manager) 2012-08-30 10:33	I think a middle-ground approach is to run pg_config if it is available and otherwise fall back to parsing the header. Any multiarch install should provide pg_config and any non-multiarch install (e.g. on Windows) should not have a forwarding header.

(0031154) Orion Poplawski (reporter) 2012-10-02 17:55	Any chance this could make it into 2.8.10?

(0031159) David Cole (manager) 2012-10-03 07:58	Probably not a high chance of this getting into 2.8.10 without an active maintainer... This issue is not on the roadmap (no "Target Version" is set), so it has not been on anybody's active radar other than the discussion seen here in the notes (and maybe some discussion on the mailing list? (not sure)) This module needs a maintainer, and somebody who can test it out on all the various platforms. Once a patch is deemed acceptable (this one still needs some work, see the previous notes) then it needs a maintainer to: - push a topic branch to the stage - merge it to 'next' - follow up on any dashboard errors or test failures for the next day (or more, until the failures are cleared up) - be available to address any issues that arise with the new code as it hits the real world in the release that follows

(0032164) Orion Poplawski (reporter) 2013-01-24 23:44	FWIW - here's an updated version of what we're currently using in Fedora.

(0042081) Kitware Robot (administrator) 2016-06-10 14:28	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2012-07-05 13:33	Orion Poplawski	New Issue
2012-07-05 13:33	Orion Poplawski	File Added: cmake-FindPostgreSQL.patch
2012-07-05 13:39	David Cole	Note Added: 0029917
2012-07-05 14:18	Orion Poplawski	Note Added: 0029918
2012-07-05 17:11	Rolf Eike Beer	Note Added: 0029923
2012-07-05 17:22	Orion Poplawski	Note Added: 0029924
2012-07-05 18:20	Rolf Eike Beer	Note Added: 0029925
2012-07-06 07:10	David Cole	Note Added: 0029927
2012-08-30 10:33	Brad King	Note Added: 0030795
2012-10-02 17:55	Orion Poplawski	Note Added: 0031154
2012-10-03 07:58	David Cole	Note Added: 0031159
2013-01-24 23:43	Orion Poplawski	File Added: cmake-FindPostgreSQL-2.patch
2013-01-24 23:44	Orion Poplawski	Note Added: 0032164
2016-06-10 14:28	Kitware Robot	Note Added: 0042081
2016-06-10 14:28	Kitware Robot	Status	new => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:28	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships