Hi,
I tested $subject again with 1.24, and it's improved significantly. Geany now installs geany.pc and the development headers properly, so the plugins build without problems. The plugin installation, however, creates a \lib directory on the installation drive, with all lib<pluginname>.dll.a files, which is completely pointless. It was the same with 1.23, but I forgot to mention it.
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. If you move geany.pc into \geany\path\lib, as in 1.23, the setting becomes used, and you'll quickly see "geanypathinclude: no such file or directory" on build. Unfortunately, waf does the opposite of pkg-config, replacing / with , so --prefix=/geany/path does not help. But the installation works, since it's done by waf, and the plugins don't care (AFAIK) what slashes are used on runtime.
BTW, the paths to Python are with \\ :)
On 16/05/14 18:41, Dimitar Zhekov wrote:
Hi,
I tested $subject again with 1.24, and it's improved significantly. Geany now installs geany.pc and the development headers properly, so the plugins build without problems. The plugin installation, however, creates a \lib directory on the installation drive, with all lib<pluginname>.dll.a files, which is completely pointless. It was the same with 1.23, but I forgot to mention it.
I know, already noticed it before 1.23, but to be honest, I just don't care.
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. If you move geany.pc into \geany\path\lib, as in 1.23, the setting becomes used, and you'll quickly see "geanypathinclude: no such file or directory" on build. Unfortunately, waf does the opposite of pkg-config, replacing / with , so --prefix=/geany/path does not help. But the installation works, since it's done by waf, and the plugins don't care (AFAIK) what slashes are used on runtime.
Not sure whether I completely understand the problem here.
I'll post soon a tutorial how I build the release binaries on Windows. Apart from this, the whole build stuff on Windows is quite fiddled and I never considered it production-ready.
Sorry.
Regards, Enrico
On Sun, 18 May 2014 15:30:21 +0200 Enrico Tröger enrico.troeger@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, though I'm not sure that gcc is to blame.
We discussed this briefly, but that was nearly a year ago ("Geany 1.23 Waf install under win32"), and apparently didn't happen on your system.
The plugin installation, however, creates a \lib directory on the installation drive, with all lib<pluginname>.dll.a files
I'll post soon a tutorial how I build the release binaries on Windows. Apart from this, the whole build stuff on Windows is quite fiddled and I never considered it production-ready.
Once the X:\lib problem is fixed, it'll be fine, unless one decides to move geany.pc to another location. Will be be nice to have the same build system working under *nix and windows-without-autotools, and we may be able to get rid of all these makefile.win32 files, which are not supported for the plugins anyway.
On 18/05/14 19:08, Dimitar Zhekov wrote:
On Sun, 18 May 2014 15:30:21 +0200 Enrico Tröger enrico.troeger@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, 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. 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 correct thing would be to use os.path.join() everywhere but this would make the wscript way harder to read, this is why I tried to avoid this.
In the .pc file, the include paths at the end still use forward slashes, these are hardcoded in geany.pc.in template. Could you check whether this causes problems as well, if so, we would need to find a solution for this.
We discussed this briefly, but that was nearly a year ago ("Geany 1.23 Waf install under win32"), and apparently didn't happen on your system.
Yeah, it did not happen for me because I never used a "real" prefix, I always use the default "geany-$VERSION" without an any path components and so I never realised what you noticed.
The plugin installation, however, creates a \lib directory on the installation drive, with all lib<pluginname>.dll.a files
I'll post soon a tutorial how I build the release binaries on Windows. Apart from this, the whole build stuff on Windows is quite fiddled and I never considered it production-ready.
Once the X:\lib problem is fixed, it'll be fine, unless one decides to move geany.pc to another location. Will be be nice to have the same
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.
Regards, Enrico
On Sat, 24 May 2014 11:55:47 +0200 Enrico Tröger enrico.troeger@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@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.
On 25/05/14 13:26, Dimitar Zhekov wrote:
On Sat, 24 May 2014 11:55:47 +0200 Enrico Tröger enrico.troeger@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@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. :)
Dammit, I was so sure we got rid of that problem now :).
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.
Ok, in 01cf9a9fdc6795b971cbad59585d33bfcb796b74 I reverted the part of replacing forward by backward slashes for the geany.pc file. And additionally I added a little hack to replace \ by / for the prefix if on Windows.
I hope that actually really improves the situation. If not, I'd be happy to accept a patch to get it fixed :).
Regards, Enrico