Created attachment 80485 [details] [review]
gnome-build-0.1.4 Cygwin patch

Sorry, can't fully separate the patches, so here's it all at once.

* configure.in
* src/Makefile.am
* src/gnu-regex/*
* src/backends/libgbf_am/Makefile.am
* src/backends/libgbf_mkfile/Makefile.am:
Incorporate gnu-regex module for those platforms which do not have a GNU <regex.h>.  Borrowed from gtksourceview.

(I've omitted the gnu-regex module itself from the patch for brevity; the gnu-regex module can be found in /gtksourceview/gtksourceview/gnu-regex/.)

* src/gbf/Makefile.am
* src/backends/libgbf_am/Makefile.am
* src/backends/libgbf_mkfile/Makefile.am:
Change libtool LDFLAGS to support other platforms.

Thanks for the patch - anyway, I will not apply it yet for the following reasons:

- gnu-regex should not be in gnome-build and gtksourceview, it should be a separate package from cygwin. Else maintaining is a nightmare. When this is done, we can of course support gnu-regex on win32. A not so good solution would a least to just link the directory in subversion which seems possible.

- Why should we change the linker flags? I just want to know whether is also affects other platform, why we need -no-undefined and if this could affect other platform, too.

Thanks,
Johannes

> gnu-regex should not be in gnome-build and gtksourceview, it should be a
> separate package from cygwin. Else maintaining is a nightmare. When this is
> done, we can of course support gnu-regex on win32.

The gtksourceview devs added gnu-regex in 2003, for portability with ALL non-glibc systems, nothing to do with Cygwin.  The module has not been changed once since originally imported over three years ago, so it shouldn't require much maintenance.

> Why should we change the linker flags? I just want to know whether is also 
> affects other platform, why we need -no-undefined and if this could affect 
> other platform, too.

-module helps Cygwin/MinGW by installing into the specified libdir instead of ../bin.  This should also help Darwin as well for technical reasons[1].

[1] http://fink.sourceforge.net/doc/porting/shared.php?phpLang=en

-avoid-version makes libtool not version the library.  On linux this isn't so noticable, since a plain .so symlink (libgbf-am.so) is created in addition to the real library (libgbf-am.so.0.y.z), but not so on Win32, so the only library would otherwise be a versioned one, e.g. cyggbf-am-0.dll instead of cyggbf-am.dll; sine modules are usually searched for by name, the versioning throws off the name detection logic.

-no-undefined tells libtool that all symbols are resolved through the libraries in LIBADD; this is required for building shared libraries on Win32.  As long as this is the case (which it must be for Win32), this flag has no effect on other platforms.

Future version of glib will include GRegex and thus make it avoidable to use any other regex code. We will switch over to the new regex stuff when it is ready.

I will try to get the other stuff applied soon.

If you need GRegex you can include the EggRegex code instead of gnu-regex. GtkSourceView is doing the same thing in the soc-2006 branch (http://svn.gnome.org/viewcvs/gtksourceview/branches/soc-2006/gtksourceview/libegg/regex/). EggRegex has the same API of GRegex, except the "egg_" prefix instead of "g_".

The code for EggRegex is at http://techn.ocracy.org/eggregex

gnome-build is (currently) only used by Anjuta. If this is the only dependency preventing Anjuta to run on cygwin, then it may be fine to have gregex in anjuta (until it becomes part of glib).

However, if there are other deps of Anjuta (what about all the gnome deps?) that are not yet ported to cygwin, there is no point in making cygwin port of gnome-build with this hack. I would suggest to port gnome-build last for Anjuta so that we avoid this unnecessary step until needed. I hope this is agreeable.

At this point, most of GNOME has been ported to Cygwin via my Cygwin Ports project, and I have been filing portable patches here along the way.

I have managed to build anjuta on Cygwin as well, although for reasons yet unknown to me it's not actually running properly, and I haven't had the time to debug it yet.

Using EggRegex instead of gnu-regex in gnome-build will take much more work than gnu-regex, as it means actually porting the code instead of just using a compatibility fix.  Also, it seems that EggRegex uses a local, outdated copy of PCRE which is subject to multiple security vulnerabilities.

The default for EggRegex (and GRegex) is to use the internal (patched) copy, but it can use the system-installed PCRE passing --enable-system-pcre to the configure script. BTW the internal version is PCRE 7.0, the latest released version of PCRE.

Sorry, I had been looking at EggRegex in libegg SVN, not from your website.

In any case, GRegex was just added to glib trunk for 2.13, so gnome-build could not be ported to GRegex until it branches for unstable development (2.19?).

Please let us know if you have patched gnome-build already, so we don't duplicate effort.

For thanks for all your work with the port!

I must admit that all this is a minor point for me as I try to solve crashers and other critical bugs in the moment to bring our beta release forward.

Anyway, of course a patch against EggRegex/GRegex would be great and is likely to be accepted but I doubt that anyone from the core developers will get to it in the next time.

Since GRegex is only in trunk -- 2.13.0 hasn't been released yet -- the porting won't be able to proceed until you create a development branch, or until glib-2.14, whichever comes first.  What is your development timeline?

Re comment 7: Anjuta is now running on Cygwin.

Okay, about include gregex what would happen if two sharedlibs that link to their own copy of gregex get loaded in the same executable (presumably, the API from the gregex are also exported together with the sharedlib)? I suspect it could be trouble in some systems. For example, if anjuta loads both gnome-build and gtksourceview, what would happen?

Something similar happened with gnome-build because of namespace conflict in some functions.

(In reply to comment #11)
> Since GRegex is only in trunk -- 2.13.0 hasn't been released yet -- the porting
> won't be able to proceed until you create a development branch, or until
> glib-2.14, whichever comes first.  What is your development timeline?
> 
Okay, here's the deal.

gnome-build only uses regexps for building projects (build/clean). Anjuta does not use that part of gnome-build because it has its own build plugin. I personally don't see it necessary for that code to still exist in gnome-build and am tempted to remove it completely.

However, since gregexp is now there in glib-2.14, I will instead just disable that part of code. We can then fix it later when glib-2.14 is released and have conditional compilation for that.

I think including EggRegex or GRegex in gnome-build is not worth doing because glib will eventually have it and anjuta does not use it.

I will also apply rest of your patch too.

Thanks for the patch. It has been applied in svn trunk.