[CMake] Interresting dependency problem

[Andreas Pakulat]

No need to Cc me, I'm reading the list.

On 28.09.07 13:37:08, Alan W. Irwin wrote:
> On 2007-09-28 21:32+0200 Andreas Pakulat wrote:
> >Well, anyway, tried it and there we are, unix-paths in the output so
> >there's no way these flags can be used in a win32 native environment.
> >However looking at the .pc files and the output of pkg-config as well as
> >pkg-config --help it seems that at least the problem with moving libs
> >and getting MSVC flags is solved. There's a --msvc-syntax switch (for
> >usage of pkg-config inside cmake this doesn't matter anyway) and it also
> >seems that some guessing happens when trying to choose a good prefix to
> >set before the /lib or /include dirs. That guessing breaks as soon as I
> >move the .pc files into a directory hierarchy that doesn't follow unix
> >style though.
> >
> >Also when using pkg-config with cmake there's still the problem of
> >having to "parse" its output and removing the various compiler flags
> >(i.e -l, -L, -I), which can fail if the paths are weird. This shows that
> >pkg-config is not being developed as a buildsystem-independent thing,
> >but at least partly bound to autotools.
>
> It appears from what you said that the pkg-config executable actually runs
> in the non-MSYS case which exactly confirms what is claimed by the
> pkg-config website.

Right, thats like rocket science, making an app run natively on windows
when its compiled for windows ;)

> As far as the rest of your objections are concerned, I believe pkg-config
> just repackages in convenient form whatever is in the *.pc files so it

Right, pkg-config itself is a rather stupid application, it just prints
some parts of the .pc file. So why should I put this thing into usage
with CMake if CMake can do all that already all on its own? Anyway...

> appears you have found some issues with *.pc files that are not configured
> properly yet for certain software packages for the windows case.

s/certain/all/ IMHO, because .pc files are created by the buildsystem
and so far I've only seen autotool packages with .pc files. autotools on
win32 produce still unix-paths, so there's no way to fix this
automatically. As I said before a simple sed 's/\//\\/' is not working
in all cases.

> I expect this to be a common issue with porting applications that are
> developed on Linux (where pkg-config is common) to windows platforms
> without MSYS.

Yes, but one thats not easily fixable unless I'm overlooking something.

> Remember, before last year when knowledge of cmake first became widespread
> in the Linux community virtually nobody was attempting to port their
> Linux-developed applications to windows platforms without MSYS.

ROFL, sorry but thats complete nonsense. Various open source projects
provide win32 native builds since a long time. You know how long Gimp
already runs on win32 without any msys?

> The important point is that now that you have shown the pkg-config
> executable actually works without MSYS, all these platform-dependent issues
> can straightforwardly be worked out.  For example, in the PLplot case we use
> CMake to configure our *.pc files in any case, and it is straightforward to
> change that configuration to any style of PATHS that is appropriate for the
> platform. Similarly, when we import pkg-config information from other
> packages using the PKG_CHECK_MODULES macro in FindPkgConfig.cmake it is
> straightforward to parse that information into the appropriate internal form
> needed by CMake.

I didn't test what happens when you try to use unix-paths with CMake on
win32. I suspect nothing good and thus you're stuck because
regex-replace is hard to do on paths.

Apart from that, you first have to convert tons of autotool projects to
CMake to make this work, autotools simply don't work natively on win32
and thus don't provide native paths for win32.

Andreas

-- 
You will gain money by a speculation or lottery.