[Geany-Devel] Geany/plugins win32 waf build/install

[Dimitar Zhekov]

On Sat, 24 May 2014 11:55:47 +0200
Enrico Tröger <enrico.troeger at uvena.de> wrote:

> On 18/05/14 19:08, Dimitar Zhekov wrote:
> > On Sun, 18 May 2014 15:30:21 +0200
> > Enrico Tröger <enrico.troeger at uvena.de> wrote:
> > 
> >> On 16/05/14 18:41, Dimitar Zhekov wrote:
> >>>
> >>> The prefix problem is workarounded. Since geany.pc is installed in
> >>> \geany\path\lib\pkgconfig now, win32 pkg-config automatically
> >>> uses /geany/path, replacing \ with / and ignoring the prefix setting.
> >>> [...]
> >>
> >> Not sure whether I completely understand the problem here.
> > 
> > With a prefix with backshahes in geany.pc (unlike the other variables,
> > and any other .pc files), my gcc decides than c:\geany\path/include is
> > c:geanypath/include. The same goes for c:\geany\path/lib et cetera,
> 
> Ah got it, finally :).
> Should be better in 1bacf869e076ef37caa768196d21d941a657d1e7,

Broke it completely. :)

> I changed the code from hard-coded forward slashes to os.path.join().
> Still, there are tons of forward slashes in the build system. If these
> cause problems at any stage, let me know.

Again: the problem is that the _backward_ slashes in the prefix (and
now the other variables) in geany.pc are treated as escape characters by
cpp, gcc or whatever. With geany.pc in "c:\what\ever\lib\pkgconfig" (in
1.24+), win32 pkg-config ignores $prefix and uses "c:/what/ever". That
doesn't any more, because $includedir became "c:/what/ever\include",
processed as "c:/what/everinclude" ("\i" does not stand for anything
particular, thus simply "i").

The fix is to revert 1bacf869e076ef37caa768196d21d941a657d1e7.
It would nice to have the prefix in geany.pc with forward slashes,
but not really important - all glib/gtk+ .pc files contain prefixes
like c:/devel/target/059c48de6b739307c37648aba3005b29, and pkg-config
ignores them as described above.

> Some applications can handle the forward slashes even on Windows,
> others not. And IIRC also Windows sometimes handle the forward
> slashes properly, sometimes not.

The Windows API-s handle forward slashes as separators since DOS 5.
The only thing I'm not sure is whether server names ("//server/path"
instead of "X:/path") work, and that may cause problems.

> >>> The plugin installation, however,
> >>> creates a \lib directory on the installation drive, with all
> >>> lib<pluginname>.dll.a files
> > 
> Yeah but I don't know yet where this path (\lib) is set in Waf and how
> to change it. I didn't consider it a real problem yet apart from the
> fact that it sort of clutters the file system.
> I might will have a look at it if time permits.

I tried to find that as well, but couldn't. The entire installation of
lib*.dll.a is useless, nobody will link against our plugin DLL-s.

-- 
E-gards: Jimmy