Hi,
I started implementing the idea of indenting based on regular expressions and have noticed that geany can be compiled without regex support. Obviously in this case the indent thing wouldn't work. I don't quite understand when someone would want to compile geany without regex. By default in configure.ac you use the system regex library. If it doesn't exist, geany is compiled without regex support. Why not to automatically fallback to using the regex library shipped with geany when system regtex library is missing so there is always some regex support? This would also remove many ugly ifdefs from the geany's code.
Cheers,
Jiri
On 14 August 2010 22:17, Jiří Techet techet@gmail.com wrote:
Hi,
I started implementing the idea of indenting based on regular expressions and have noticed that geany can be compiled without regex support. Obviously in this case the indent thing wouldn't work. I don't quite understand when someone would want to compile geany without regex. By default in configure.ac you use the system regex library. If it doesn't exist, geany is compiled without regex support. Why not to automatically fallback to using the regex library shipped with geany when system regtex library is missing so there is always some regex support? This would also remove many ugly ifdefs from the geany's code.
Hi Jiri,
I'd agree that using regex should be the default, either the system or the included one or glib regex .... lots of choices.
Cheers Lex
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 15 Aug 2010 13:55:11 +1000, Lex wrote:
On 14 August 2010 22:17, Jiří Techet techet@gmail.com wrote:
Hi,
I started implementing the idea of indenting based on regular expressions and have noticed that geany can be compiled without regex support. Obviously in this case the indent thing wouldn't work. I don't quite understand when someone would want to compile geany without regex. By default in configure.ac you use the system regex library. If it doesn't exist, geany is compiled without regex support. Why not to automatically fallback to using the regex
If this is the case, it's a bug. At least IIRC the shipped regex support should be used as fallback. But I didn't use the autotools based build for ages. Anyway, the idea always was to build against the system's regex implementation if available and if not (like on Windows), fall back to the shipped mini implementation.
The Waf based build system builds with the shipped mini implementation if the --enable-gnu-regex option is given. Otherwise it checks whether the system provides something usable and uses this and if not, it uses the shipped variant.
If this doesn't work similar for the autotools, it's probably a bug.
Regards, Enrico
2010/8/15 Enrico Tröger enrico.troeger@uvena.de:
On Sun, 15 Aug 2010 13:55:11 +1000, Lex wrote:
On 14 August 2010 22:17, Jiří Techet techet@gmail.com wrote:
Hi,
I started implementing the idea of indenting based on regular expressions and have noticed that geany can be compiled without regex support. Obviously in this case the indent thing wouldn't work. I don't quite understand when someone would want to compile geany without regex. By default in configure.ac you use the system regex library. If it doesn't exist, geany is compiled without regex support. Why not to automatically fallback to using the regex
If this is the case, it's a bug. At least IIRC the shipped regex support should be used as fallback. But I didn't use the autotools based build for ages. Anyway, the idea always was to build against the system's regex implementation if available and if not (like on Windows), fall back to the shipped mini implementation.
The Waf based build system builds with the shipped mini implementation if the --enable-gnu-regex option is given. Otherwise it checks whether the system provides something usable and uses this and if not, it uses the shipped variant.
If this doesn't work similar for the autotools, it's probably a bug.
I've checked the wscript and it seems to do the right thing. However unless I miss something in configure.ac, you first check for system regex library and then do:
# Use included GNU regex library AC_ARG_ENABLE(gnu-regex, [AC_HELP_STRING([--enable-gnu-regex], [compile with included GNU regex library [default=no]])], , enable_gnu_regex=no)
if test "x$enable_gnu_regex" = "xyes" ; then AC_DEFINE(USE_INCLUDED_REGEX, 1, [Define if included GNU regex code should be used.]) AC_DEFINE(HAVE_REGCOMP, 1, [Define if you have the 'regcomp' function.]) AM_CONDITIONAL(USE_INCLUDED_REGEX, true) else AM_CONDITIONAL(USE_INCLUDED_REGEX, false) fi
So if you don't use --enable-gnu-regex, the else branch is taken and if HAVE_REGCOMP wasn't defined in the system then geany is compiled without regex support. I can send a patch to fix that.
If we have regular expression support under any condition, then I would also like to remove all the #ifdef HAVE_REGCOMP in geany sources. There is also code like
#ifndef HAVE_REGCOMP if (!NZV(regstr)) geany_debug("No regex support - maybe you should configure with --enable-gnu-regex!"); return FALSE; #else
which would be a dead code if HAVE_REGCOMP is always defined. Also I don't want to code any fallback solution for the indentation code if regex library is missing in the system.
Jiri
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 15 Aug 2010 14:37:38 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
I started implementing the idea of indenting based on regular expressions and have noticed that geany can be compiled without regex support. Obviously in this case the indent thing wouldn't work. I don't quite understand when someone would want to compile geany without regex. By default in configure.ac you use the system regex library. If it doesn't exist, geany is compiled without regex support. Why not to automatically fallback to using the regex
If this is the case, it's a bug. At least IIRC the shipped regex support should be used as fallback. But I didn't use the autotools based build for ages. Anyway, the idea always was to build against the system's regex implementation if available and if not (like on Windows), fall back to the shipped mini implementation.
The Waf based build system builds with the shipped mini implementation if the --enable-gnu-regex option is given. Otherwise it checks whether the system provides something usable and uses this and if not, it uses the shipped variant.
If this doesn't work similar for the autotools, it's probably a bug.
I think configure.ac needs to be fixed to do this.
Then we can remove all #ifdef HAVE_REGCOMP lines (in fact we should probably remove them anyway).
Regards, Nick
On Sun, 15 Aug 2010 13:55:11 +1000 Lex Trotman elextr@gmail.com wrote:
I'd agree that using regex should be the default, either the system or the included one or glib regex .... lots of choices.
Not the GLib one, the version that provides it isn't required by Geany.
Regards, Nick
On Mon, 16 Aug 2010 17:02:45 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
The Waf based build system builds with the shipped mini implementation if the --enable-gnu-regex option is given. Otherwise it checks whether the system provides something usable and uses this and if not, it uses the shipped variant.
If this doesn't work similar for the autotools, it's probably a bug.
I think configure.ac needs to be fixed to do this.
I've done this now but I'm not sure how to test it works when the system doesn't provide regex.
Then we can remove all #ifdef HAVE_REGCOMP lines (in fact we should probably remove them anyway).
Now done for src, left checks in tagmanager.
Regards, Nick
(OK, the mailing list doesn't like posts with bigger attachments. Resending the email with the compressed patch.)
On Wed, Aug 25, 2010 at 13:46, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 16 Aug 2010 17:02:45 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
The Waf based build system builds with the shipped mini implementation if the --enable-gnu-regex option is given. Otherwise it checks whether the system provides something usable and uses this and if not, it uses the shipped variant.
If this doesn't work similar for the autotools, it's probably a bug.
I think configure.ac needs to be fixed to do this.
I've done this now but I'm not sure how to test it works when the system doesn't provide regex.
Then we can remove all #ifdef HAVE_REGCOMP lines (in fact we should probably remove them anyway).
Now done for src, left checks in tagmanager.
Ah, good, it seems that we have been doing the same thing in parallel :-). The only functional difference in my patch was that I also used a separate AC_CHECK_HEADERS check for regex.h similarly to what you did for regcomp with AC_CHECK_FUNCS. I could test the AC_CHECK_HEADERS test by renaming the system regex.h to something else - the strange thing was that AC_CHECK_FUNCS always executed the if-found condition no matter what the header name was. I have no idea how AC_CHECK_FUNCS performs the check :-(.
Attached you'll find a patch that updates the regex library to the latest version from glibc. This removes the warnings Lex was experiencing on a 64bit machine. I looked at how ctags does it and made the patch in a similar way. I've only updated the automake based build - I have no experience with waf and felt a bit lazy to learn it but should be easy for someone who is familiar with it.
It's good you've left the checks in tagmanager. I have a series of patches (under tm_cleanup branch in my git clone) that makes the ctags part of tagmanager as close to mainline as possible (but preserving all tagmanager extensions and geany's parsers of individual languages). I haven't published this patch series here yet - I'll wait until my remaining patches get reviewed so there are not too many patches flying around.
Regards,
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 25 Aug 2010 21:47:08 +0200 Jiří Techet techet@gmail.com wrote:
Attached you'll find a patch that updates the regex library to the latest version from glibc. This removes the warnings Lex was experiencing on a 64bit machine. I looked at how ctags does it and made the patch in a similar way.
I'm not sure if the glibc version will build on Windows. I don't have a Windows build environment set up ATM to try it.
It might be best to use the version from latest CTags. The gnu_regex/README.txt says: "Minor changes were made to eliminate compiler errors and warnings."
Using the same version as CTags could potentially also prevent any regex-incompatibility bugs with CTags parsers.
Regards, Nick
On Tue, Oct 5, 2010 at 17:03, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 25 Aug 2010 21:47:08 +0200 Jiří Techet techet@gmail.com wrote:
Attached you'll find a patch that updates the regex library to the latest version from glibc. This removes the warnings Lex was experiencing on a 64bit machine. I looked at how ctags does it and made the patch in a similar way.
I'm not sure if the glibc version will build on Windows. I don't have a Windows build environment set up ATM to try it.
It might be best to use the version from latest CTags. The gnu_regex/README.txt says: "Minor changes were made to eliminate compiler errors and warnings."
Using the same version as CTags could potentially also prevent any regex-incompatibility bugs with CTags parsers.
As far as I remember the CTags version and the glibc version of regex are basically the same. I also changed some symbol name in the regex sources because of a conflict with some symbol in my system header files.
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 12 Oct 2010 14:30:00 +0200 Jiří Techet techet@gmail.com wrote:
Attached you'll find a patch that updates the regex library to the latest version from glibc. This removes the warnings Lex was experiencing on a 64bit machine. I looked at how ctags does it and made the patch in a similar way.
I'm not sure if the glibc version will build on Windows. I don't have a Windows build environment set up ATM to try it.
It might be best to use the version from latest CTags. The gnu_regex/README.txt says: "Minor changes were made to eliminate compiler errors and warnings."
Using the same version as CTags could potentially also prevent any regex-incompatibility bugs with CTags parsers.
As far as I remember the CTags version and the glibc version of regex are basically the same.
They're not the same, the diff is significant.
I think we should use the CTags version.
I also changed some symbol name in the regex sources because of a conflict with some symbol in my system header files.
What's the conflicting symbol?
Regards, Nick
On Fri, Oct 15, 2010 at 14:24, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 12 Oct 2010 14:30:00 +0200 Jiří Techet techet@gmail.com wrote:
Attached you'll find a patch that updates the regex library to the latest version from glibc. This removes the warnings Lex was experiencing on a 64bit machine. I looked at how ctags does it and made the patch in a similar way.
I'm not sure if the glibc version will build on Windows. I don't have a Windows build environment set up ATM to try it.
It might be best to use the version from latest CTags. The gnu_regex/README.txt says: "Minor changes were made to eliminate compiler errors and warnings."
Using the same version as CTags could potentially also prevent any regex-incompatibility bugs with CTags parsers.
As far as I remember the CTags version and the glibc version of regex are basically the same.
They're not the same, the diff is significant.
OK, was doing it some time ago so I was probably wrong.
I think we should use the CTags version.
I also changed some symbol name in the regex sources because of a conflict with some symbol in my system header files.
What's the conflicting symbol?
It was in regex_internal.h - I had to change:
# define __mempcpy mempcpy
to
# define ___mempcpy mempcpy
but I expect CTags fixed this somehow too.
Regards,
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel