Hi All, and especially build system maintainers :)
I have made a pull request[0] to cleanup the symbol exports of Geany. The PR description pretty much covers the details. If I merge this, it's going to break the makefile.win32 files, Waf and possibly the Win32 Nightly builds.
I can probably fix-up the makefile.win32 files if nobody else will as it's just plain GNU make and should be similar changes as the Autotools. It will require a couple more *nix utilities, namely `sed`, `sort`, and `uniq` (or a `sort` that supports the `-u` option). A quick search finds sed[1] and coreutils[2] which contains `sort` (probably with -u option) and `uniq`. I assume MSYS also includes these common utils.
I don't really know enough about Waf to fix it. Since it needs Python anyway, we could just use one of its XML libraries to grab the names from the GtkBuilder file, and do the replacements using its text-handling functions. It wouldn't require sed/sort utils. I originally had a Python script[3] doing this, but I'm just not sure how to integrate that code into Waf.
If the Win32 Nightlies break it will most likely be trivial changes to the Makefile.ams. I don't have an environment like it uses to test.
Geany-Plugins Autotools should be fine since it will pickup the new library from the pkg-config flags. There's a couple bugs in some (of my) plugins where it misses the needed linker flags which are trivial to fix. I don't know if Waf uses pkg-config or what, but if not, it will need to add the equivalent of something like `-L/geanys/lib/dir -lgeany` to be able to find and link to the new library.
Is everyone OK if this PR was merged to master and we had to fix up some build system stuff? Alternatively, I could also add anyone for push rights on my geany fork or push it to a branch on main geany repo if we wanted to sort-out the integration issues before merging to the main master branch.
Cheers, Matthew Brush
[0]: https://github.com/geany/geany/pull/358 [1]: http://gnuwin32.sourceforge.net/packages/sed.htm [2]: http://gnuwin32.sourceforge.net/packages/coreutils.htm [3]: https://raw.githubusercontent.com/codebrainz/geany/74d21da4570c777a4a112b743...
Hi,
I don't really know enough about Waf to fix it. Since it needs Python anyway, we could just use one of its XML libraries to grab the names from the GtkBuilder file, and do the replacements using its text-handling functions. It wouldn't require sed/sort utils. I originally had a Python script[3] doing this, but I'm just not sure how to integrate that code into Waf.
I' work on the Waf part but this will take at least two weeks as I'm almost not on the PC during the next two weeks.
If the Win32 Nightlies break it will most likely be trivial changes to the Makefile.ams. I don't have an environment like it uses to test.
The Win32 nightlies are built using Waf, so fixing Waf will fix it all :).
Geany-Plugins Autotools should be fine since it will pickup the new
I checked out codebrainz/wip/linkage-cleanup but got build errors with autotools:
-----------snip------------- tm_source_file.c:31:60: fatal error: ../src/pluginexport.h: No such file or directory #include "../src/pluginexport.h" /* for GEANY_API_SYMBOL */ ^ compilation terminated. Makefile:490: recipe for target 'tm_source_file.lo' failed -----------snap-------------
src/pluginexport.h seems missing?
Is everyone OK if this PR was merged to master and we had to fix up some build system stuff? Alternatively, I could also add anyone for push rights on my geany fork or push it to a branch on main geany repo if we wanted to sort-out the integration issues before merging to the main master branch.
I don't mind which way to take.
Regards, Enrico
On 14-10-26 07:14 AM, Enrico Tröger wrote:
Hi,
I don't really know enough about Waf to fix it. Since it needs Python anyway, we could just use one of its XML libraries to grab the names from the GtkBuilder file, and do the replacements using its text-handling functions. It wouldn't require sed/sort utils. I originally had a Python script[3] doing this, but I'm just not sure how to integrate that code into Waf.
I' work on the Waf part but this will take at least two weeks as I'm almost not on the PC during the next two weeks.
OK.
If the Win32 Nightlies break it will most likely be trivial changes to the Makefile.ams. I don't have an environment like it uses to test.
The Win32 nightlies are built using Waf, so fixing Waf will fix it all :).
I thought the nightlies were using Mingw because there's all those duplicate code paths in the Makefile.ams for Mingw. Who uses those?
Geany-Plugins Autotools should be fine since it will pickup the new
I checked out codebrainz/wip/linkage-cleanup but got build errors with autotools:
-----------snip------------- tm_source_file.c:31:60: fatal error: ../src/pluginexport.h: No such file or directory #include "../src/pluginexport.h" /* for GEANY_API_SYMBOL */ ^ compilation terminated. Makefile:490: recipe for target 'tm_source_file.lo' failed -----------snap-------------
src/pluginexport.h seems missing?
Oops, I had this file ignored locally for some reason. I squashed it into the correct commit and force pushed it. It should be OK now.
Cheers, Matthew Brush
On 26/10/14 18:25, Matthew Brush wrote:
On 14-10-26 07:14 AM, Enrico Tröger wrote:
Hi,
I don't really know enough about Waf to fix it. Since it needs Python anyway, we could just use one of its XML libraries to grab the names from the GtkBuilder file, and do the replacements using its text-handling functions. It wouldn't require sed/sort utils. I originally had a Python script[3] doing this, but I'm just not sure how to integrate that code into Waf.
I' work on the Waf part but this will take at least two weeks as I'm almost not on the PC during the next two weeks.
OK.
I got a very basic working version, see attachment. However, I almost didn't test it and things like library versioning are missing. As said, the rest will take some time.
If the Win32 Nightlies break it will most likely be trivial changes to the Makefile.ams. I don't have an environment like it uses to test.
The Win32 nightlies are built using Waf, so fixing Waf will fix it all :).
I thought the nightlies were using Mingw because there's all those duplicate code paths in the Makefile.ams for Mingw. Who uses those?
We added those years ago to support cross-compilation. IIRC this was before Waf. Yeah, we really should consolidate the available build systems and clean up the rest :). I don't use autotools based cross-compilation.
Geany-Plugins Autotools should be fine since it will pickup the new
I checked out codebrainz/wip/linkage-cleanup but got build errors with autotools:
-----------snip------------- tm_source_file.c:31:60: fatal error: ../src/pluginexport.h: No such file or directory #include "../src/pluginexport.h" /* for GEANY_API_SYMBOL */ ^ compilation terminated. Makefile:490: recipe for target 'tm_source_file.lo' failed -----------snap-------------
src/pluginexport.h seems missing?
Oops, I had this file ignored locally for some reason. I squashed it into the correct commit and force pushed it. It should be OK now.
Thanks, it builds fine now.
Regards, Enrico
On 14-10-26 04:16 PM, Enrico Tröger wrote:
On 26/10/14 18:25, Matthew Brush wrote:
On 14-10-26 07:14 AM, Enrico Tröger wrote:
Hi,
I don't really know enough about Waf to fix it. Since it needs Python anyway, we could just use one of its XML libraries to grab the names from the GtkBuilder file, and do the replacements using its text-handling functions. It wouldn't require sed/sort utils. I originally had a Python script[3] doing this, but I'm just not sure how to integrate that code into Waf.
I' work on the Waf part but this will take at least two weeks as I'm almost not on the PC during the next two weeks.
OK.
I got a very basic working version, see attachment. However, I almost didn't test it and things like library versioning are missing.
In Autotools libtool versions is not used yet anyway. It's just set to 0:0:0 same as the defaults. I just added that for future use.
As said, the rest will take some time.
OK.
If the Win32 Nightlies break it will most likely be trivial changes to the Makefile.ams. I don't have an environment like it uses to test.
The Win32 nightlies are built using Waf, so fixing Waf will fix it all :).
I thought the nightlies were using Mingw because there's all those duplicate code paths in the Makefile.ams for Mingw. Who uses those?
We added those years ago to support cross-compilation. IIRC this was before Waf. Yeah, we really should consolidate the available build systems and clean up the rest :). I don't use autotools based cross-compilation.
This is good news. I have done work on Win32/MSYS Autotools but I didn't want to break this special path which is same/similar I needed. Some day I will push some changes to consolidate both branches in Makefile.ams and having a working Win32/MSYS Autotools :)
Cheers, Matthew Brush
On 27/10/14 02:14, Matthew Brush wrote:
On 14-10-26 04:16 PM, Enrico Tröger wrote:
On 26/10/14 18:25, Matthew Brush wrote:
On 14-10-26 07:14 AM, Enrico Tröger wrote:
Hi,
I don't really know enough about Waf to fix it. Since it needs Python anyway, we could just use one of its XML libraries to grab the names from the GtkBuilder file, and do the replacements using its text-handling functions. It wouldn't require sed/sort utils. I originally had a Python script[3] doing this, but I'm just not sure how to integrate that code into Waf.
I' work on the Waf part but this will take at least two weeks as I'm almost not on the PC during the next two weeks.
OK.
I got a very basic working version, see attachment. However, I almost didn't test it and things like library versioning are missing.
In Autotools libtool versions is not used yet anyway. It's just set to 0:0:0 same as the defaults. I just added that for future use.
I got versioning working, for now the library will be installed as 0.0.0 like the autotools based build.
How do we want to proceed, should I commit the changes to your repo or PR?
Regards, Enrico
On 14-11-09 07:31 AM, Enrico Tröger wrote:
On 27/10/14 02:14, Matthew Brush wrote:
On 14-10-26 04:16 PM, Enrico Tröger wrote:
On 26/10/14 18:25, Matthew Brush wrote:
On 14-10-26 07:14 AM, Enrico Tröger wrote:
Hi,
I don't really know enough about Waf to fix it. Since it needs Python anyway, we could just use one of its XML libraries to grab the names from the GtkBuilder file, and do the replacements using its text-handling functions. It wouldn't require sed/sort utils. I originally had a Python script[3] doing this, but I'm just not sure how to integrate that code into Waf.
I' work on the Waf part but this will take at least two weeks as I'm almost not on the PC during the next two weeks.
OK.
I got a very basic working version, see attachment. However, I almost didn't test it and things like library versioning are missing.
In Autotools libtool versions is not used yet anyway. It's just set to 0:0:0 same as the defaults. I just added that for future use.
I got versioning working, for now the library will be installed as 0.0.0 like the autotools based build.
How do we want to proceed, should I commit the changes to your repo or PR?
Yeah, that'd be fine. I think Colomban added some commits just recently too so you might want to rebase ontop of that before pushing. The `pluginexport.h` header is gone now and `GEANY_API_SYMBOL` needs to be defined by the build system.
Cheers, Matthew Brush
Hi,
> I don't really know enough about Waf to fix it. Since it needs > Python > anyway, we could just use one of its XML libraries to grab the names > from the GtkBuilder file, and do the replacements using its > text-handling functions. It wouldn't require sed/sort utils. I > originally had a Python script[3] doing this, but I'm just not sure > how > to integrate that code into Waf.
I' work on the Waf part but this will take at least two weeks as I'm almost not on the PC during the next two weeks.
OK.
I got a very basic working version, see attachment. However, I almost didn't test it and things like library versioning are missing.
In Autotools libtool versions is not used yet anyway. It's just set to 0:0:0 same as the defaults. I just added that for future use.
I got versioning working, for now the library will be installed as 0.0.0 like the autotools based build.
How do we want to proceed, should I commit the changes to your repo or PR?
Yeah, that'd be fine. I think Colomban added some commits just recently too so you might want to rebase ontop of that before pushing. The `pluginexport.h` header is gone now and `GEANY_API_SYMBOL` needs to be defined by the build system.
Sorry for the delay :(. I finally pushed my changes and also improved Colomban's later changes regarding Waf and GEANY_*_SYMBOL flags.
Regards, Enrico
On 14-10-26 04:16 PM, Enrico Tröger wrote:
On 26/10/14 18:25, Matthew Brush wrote:
On 14-10-26 07:14 AM, Enrico Tröger wrote:
[snip]
If the Win32 Nightlies break it will most likely be trivial changes to the Makefile.ams. I don't have an environment like it uses to test.
The Win32 nightlies are built using Waf, so fixing Waf will fix it all :).
I thought the nightlies were using Mingw because there's all those duplicate code paths in the Makefile.ams for Mingw. Who uses those?
We added those years ago to support cross-compilation. IIRC this was before Waf. Yeah, we really should consolidate the available build systems and clean up the rest :). I don't use autotools based cross-compilation.
I had a try at this for a while and after a number of changes it's almost working. I got past the build system, compiler, and linker problems, but now it's giving grief because of the "non-standard" (with respect to Autotools) directory layout and the special cases we have about using a "data" directory instead of putting in "share/geany".
Is there any possibility we could use the same Unixey directory layout for Win32 builds too?
My dream is in some distant future to have the Autotools build system able to build natively and cross-compiled and adding rules needed to make the Windows installer and everything. This would also be great for continuous integration and/or nightly builds in the future too, as we would mostly have the exact same build system with the same compiler/linker options and only minor differences to satisfy the differences between platforms.
Just think of how much easier it would be if at release time all you had to do was:
make dist-win32
And just upload the resulting installer .exe[0] :)
Cheers, Matthew Brush
[0]: Which would be the exact same installer .exe everyone's been testing with from the CI/nightlies all along.
Le 29/10/2014 06:48, Matthew Brush a écrit :
On 14-10-26 04:16 PM, Enrico Tröger wrote:
[…] I don't use autotools based cross-compilation.
I had a try at this for a while and after a number of changes it's almost working. I got past the build system, compiler, and linker problems, […]
FWIW I pushed the changes I did myself (hey ;) to https://github.com/b4n/geany/commits/wip/autotools-mingw-cross just in case it can be of some use.
Enrico: would the change on geany_private.rc from https://github.com/b4n/geany/commit/a24d9217c3dfb959b4138fe3bffd871d9dc88ba4 break Waf or something else? (yes, I could check by running a VM, but I can also ask first :)
When we merge #356 we can probably drop libiberty altogether as the only code we have that definitively depend on `fnmatch()` is in `tm_file_entry.c` (which is unused, and removed by the PR). BTW, if I'm not mistaken our check for fnmatch are currently wrong on any platforms, as:
1) the check is not a strict requirement, yet I believe it is required 2) it never defines HAVE_FNMATCH yet it's what CTags' strlist checks for (though it's not a strict requirement in CTags, it just make the test useless there)
It'd be easy to fix however, but if we remove it in two dais it doesn't matter much.
Regards, Colomban
On 29/10/14 16:17, Colomban Wendling wrote:
Le 29/10/2014 06:48, Matthew Brush a écrit :
On 14-10-26 04:16 PM, Enrico Tröger wrote:
[…] I don't use autotools based cross-compilation.
I had a try at this for a while and after a number of changes it's almost working. I got past the build system, compiler, and linker problems, […]
FWIW I pushed the changes I did myself (hey ;) to https://github.com/b4n/geany/commits/wip/autotools-mingw-cross just in case it can be of some use.
Enrico: would the change on geany_private.rc from https://github.com/b4n/geany/commit/a24d9217c3dfb959b4138fe3bffd871d9dc88ba4 break Waf or something else? (yes, I could check by running a VM, but I can also ask first :)
I tested it on my VM and assumed it would break the build but surprisingly it does not. I don't know why but at least with Waf, using icons/geany.ico works as well as ../icons/geany.ico. I cannot really explain it but your change doesn't break the build.
Regards, Enrico
Le 09/11/2014 16:15, Enrico Tröger a écrit :
On 29/10/14 16:17, Colomban Wendling wrote:
[...]
Enrico: would the change on geany_private.rc from https://github.com/b4n/geany/commit/a24d9217c3dfb959b4138fe3bffd871d9dc88ba4 break Waf or something else? (yes, I could check by running a VM, but I can also ask first :)
I tested it on my VM and assumed it would break the build but surprisingly it does not. I don't know why but at least with Waf, using icons/geany.ico works as well as ../icons/geany.ico. I cannot really explain it but your change doesn't break the build.
Great then. I also tried to build with Waf on Windows with this patch and it didn't complain.
So, I made a PR https://github.com/geany/geany/pull/377 please give it a quick look and tell me if you see anything absurd. It should be OK though, as I successfully built a mostly-working executable with it :)
Cheers, Colomban
On 09/11/14 17:57, Colomban Wendling wrote:
Le 09/11/2014 16:15, Enrico Tröger a écrit :
On 29/10/14 16:17, Colomban Wendling wrote:
[...]
Enrico: would the change on geany_private.rc from https://github.com/b4n/geany/commit/a24d9217c3dfb959b4138fe3bffd871d9dc88ba4 break Waf or something else? (yes, I could check by running a VM, but I can also ask first :)
I tested it on my VM and assumed it would break the build but surprisingly it does not. I don't know why but at least with Waf, using icons/geany.ico works as well as ../icons/geany.ico. I cannot really explain it but your change doesn't break the build.
Great then. I also tried to build with Waf on Windows with this patch and it didn't complain.
So, I made a PR https://github.com/geany/geany/pull/377 please give it a quick look and tell me if you see anything absurd. It should be OK though, as I successfully built a mostly-working executable with it :)
Sorry for the delay, I commented on the PR.
Regards, Enrico
On 29/10/14 06:48, Matthew Brush wrote:
On 14-10-26 04:16 PM, Enrico Tröger wrote:
On 26/10/14 18:25, Matthew Brush wrote:
On 14-10-26 07:14 AM, Enrico Tröger wrote:
[snip]
If the Win32 Nightlies break it will most likely be trivial changes to the Makefile.ams. I don't have an environment like it uses to test.
The Win32 nightlies are built using Waf, so fixing Waf will fix it all :).
I thought the nightlies were using Mingw because there's all those duplicate code paths in the Makefile.ams for Mingw. Who uses those?
We added those years ago to support cross-compilation. IIRC this was before Waf. Yeah, we really should consolidate the available build systems and clean up the rest :). I don't use autotools based cross-compilation.
I had a try at this for a while and after a number of changes it's almost working. I got past the build system, compiler, and linker problems, but now it's giving grief because of the "non-standard" (with respect to Autotools) directory layout and the special cases we have about using a "data" directory instead of putting in "share/geany".
Is there any possibility we could use the same Unixey directory layout for Win32 builds too?
I guess so without having it well thought out. It would be nice indeed.
My dream is in some distant future to have the Autotools build system able to build natively and cross-compiled and adding rules needed to make the Windows installer and everything. This would also be great for continuous integration and/or nightly builds in the future too, as we would mostly have the exact same build system with the same compiler/linker options and only minor differences to satisfy the differences between platforms.
That sounds really sweet and would ease development and releasing but would require quite some work before to get it working.
Regards, Enrico
On 25/10/2014 19:37, Matthew Brush wrote:
I can probably fix-up the makefile.win32 files if nobody else will as it's just plain GNU make and should be similar changes as the Autotools.
OK.
It will require a couple more *nix utilities, namely `sed`, `sort`, and `uniq` (or a `sort` that supports the `-u` option). A quick search finds sed[1] and coreutils[2] which contains `sort` (probably with -u option) and `uniq`. I assume MSYS also includes these common utils.
I suppose that's OK. The doc target already needs sed, but building the docs is optional. We might want to either require MSYS to build on Windows (currently it's an option), or otherwise update the website instructions about how to install the other utilities.