Thread: [A-a-p-user] Automatic dependency checking problems
Brought to you by:
vimboss
From: Thore K. <si...@65...> - 2004-05-06 16:55:13
|
I'm having some issues with this. First: I'm running AAP under cygwin, but I'm compiling with MSVC. This means that gcc can be found, so AAP will default to using that to generate the dependencies. This doesn't work, for a couple of reasons: 1. gcc doesn't understand the MSVC compiler flags. 2. The dependency files use .o for object files, not .obj which is the standard suffix for the windows platform. It would be good if I could tell AAP not to try to use gcc for dependency checking, regardless of whether it's found or not. There doesn't seem to be a good way to do this. There is also a problem with the built-in dependency checking function, aap_depend_c. It doesn't automatically look in the directory of a source file for the header file. If the directory structure is like this: main.aap Project/main.cpp Project/main.h main.h will not be listed as a dependency, because main.h can't be found in the list of directories aap_depend_c searches. It should automatically search the Project directory, because that's what C/C++ compilers do. I've worked around the above problems by adding this to my recipe: :action depend {recursive} c,cpp @srcpath = os.path.dirname(var2list(source)[0]) @aap_depend_c(globals(), source, target, @ flags = "-I%s %s" % (srcpath, _no.INCLUDE)) However, it would be nice if there was a cleaner way. -- Be seeing you. |
From: Bram M. <Br...@mo...> - 2004-05-06 18:37:29
|
Thore Karlsen wrote: > I'm having some issues with this. > > First: I'm running AAP under cygwin, but I'm compiling with MSVC. This > means that gcc can be found, so AAP will default to using that to > generate the dependencies. This doesn't work, for a couple of reasons: > > 1. gcc doesn't understand the MSVC compiler flags. > 2. The dependency files use .o for object files, not .obj which is the > standard suffix for the windows platform. > > It would be good if I could tell AAP not to try to use gcc for > dependency checking, regardless of whether it's found or not. There > doesn't seem to be a good way to do this. This is actually mentioned in the default.aap recipe as a todo item. I would think that when $CC is set to use MSVC, the test that gcc exists should fail and Aap will use aap_depend_c() instead. Why doesn't it work that way? Is $CC still set to gcc perhaps? > There is also a problem with the built-in dependency checking function, > aap_depend_c. It doesn't automatically look in the directory of a source > file for the header file. If the directory structure is like this: > > main.aap > Project/main.cpp > Project/main.h > > main.h will not be listed as a dependency, because main.h can't be found > in the list of directories aap_depend_c searches. It should > automatically search the Project directory, because that's what C/C++ > compilers do. The order in which directories are searched for include files is often a cause of trouble. I think when using a file in double quotes the search always looks in the directory of the source file first. When using <> that is skipped. My old K&R C book mentions this. The code apparently uses the current directory instead of the directory of the source file. I suppose that's wrong. Please try this patch: *** RecPython.py~ Mon Mar 8 20:17:37 2004 --- RecPython.py Thu May 6 19:58:10 2004 *************** *** 864,870 **** scanned = {os.path.abspath(source) : 0} # Make the local pathlist from "-Idir" arguments. ! localpathlist = [ "." ] if flags is None: flags = get_var_val_int(recdict, "CFLAGS") for n in [get_var_val_int(recdict, "CPPFLAGS"), --- 864,872 ---- scanned = {os.path.abspath(source) : 0} # Make the local pathlist from "-Idir" arguments. ! # Should we include the current directory? Probably not. We do look in ! # the directory of the source file when double quotes are used. ! localpathlist = [ ] if flags is None: flags = get_var_val_int(recdict, "CFLAGS") for n in [get_var_val_int(recdict, "CPPFLAGS"), *************** *** 951,956 **** --- 953,962 ---- msg_extra(recdict, _('Cannot find included file "%s"' % fname)) return + mypath = os.path.dirname(fname) + if mypath == '': + mypath = '.' + f = open(fname) msg_extra(recdict, _('Scanning "%s" for dependencies') % fname) *************** *** 987,993 **** # Search for the file in the specified path for # include files. if quote == '"': ! pathlist = localpathlist + globalpathlist else: pathlist = globalpathlist + localpathlist fn = search_path(pathlist, line[s:i]) --- 993,999 ---- # Search for the file in the specified path for # include files. if quote == '"': ! pathlist = [ mypath ] + localpathlist + globalpathlist else: pathlist = globalpathlist + localpathlist fn = search_path(pathlist, line[s:i]) -- hundred-and-one symptoms of being an internet addict: 140. You'd rather catch a score on the web than watch the game as it is being played on tv. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Thore K. <si...@65...> - 2004-05-06 19:33:38
|
On Thu, 06 May 2004 20:37:00 +0200, Bram Moolenaar <Br...@mo...> wrote: >> I'm having some issues with this. >> >> First: I'm running AAP under cygwin, but I'm compiling with MSVC. This >> means that gcc can be found, so AAP will default to using that to >> generate the dependencies. This doesn't work, for a couple of reasons: >> >> 1. gcc doesn't understand the MSVC compiler flags. >> 2. The dependency files use .o for object files, not .obj which is the >> standard suffix for the windows platform. >> >> It would be good if I could tell AAP not to try to use gcc for >> dependency checking, regardless of whether it's found or not. There >> doesn't seem to be a good way to do this. >This is actually mentioned in the default.aap recipe as a todo item. > >I would think that when $CC is set to use MSVC, the test that gcc exists >should fail and Aap will use aap_depend_c() instead. Why doesn't it >work that way? Is $CC still set to gcc perhaps? When I run AAP in cygwin, AAP defaults to using gcc. I have ":usetool MSVC" in my recipe. However, the gcccheck action has cc for $CC and gcc for $CXX. I assume this is because the value of these variables is substituted when the action is parsed, and not when it is actually invoked? [...] >The order in which directories are searched for include files is often a >cause of trouble. I think when using a file in double quotes the search >always looks in the directory of the source file first. When using <> >that is skipped. My old K&R C book mentions this. > >The code apparently uses the current directory instead of the directory >of the source file. I suppose that's wrong. Please try this patch: [...] This does appear to have done the trick. I had to trick AAP into believing that gcc wasn't present to get it to use aap_depend_c(), though. -- Be seeing you. |
From: Bram M. <Br...@mo...> - 2004-05-06 20:58:03
|
Thore Karlsen wrote: > On Thu, 06 May 2004 20:37:00 +0200, Bram Moolenaar > <Br...@mo...> wrote: > > >> I'm having some issues with this. > >> > >> First: I'm running AAP under cygwin, but I'm compiling with MSVC. This > >> means that gcc can be found, so AAP will default to using that to > >> generate the dependencies. This doesn't work, for a couple of reasons: > >> > >> 1. gcc doesn't understand the MSVC compiler flags. > >> 2. The dependency files use .o for object files, not .obj which is the > >> standard suffix for the windows platform. > >> > >> It would be good if I could tell AAP not to try to use gcc for > >> dependency checking, regardless of whether it's found or not. There > >> doesn't seem to be a good way to do this. > > >This is actually mentioned in the default.aap recipe as a todo item. > > > >I would think that when $CC is set to use MSVC, the test that gcc exists > >should fail and Aap will use aap_depend_c() instead. Why doesn't it > >work that way? Is $CC still set to gcc perhaps? > > When I run AAP in cygwin, AAP defaults to using gcc. I have ":usetool > MSVC" in my recipe. However, the gcccheck action has cc for $CC and gcc > for $CXX. I assume this is because the value of these variables is > substituted when the action is parsed, and not when it is actually > invoked? No, they are expanded when the action is invoked. I think the problem simply is that the msvc tool doesn't set $CC or $CXX. It only sets $MSVC. So, should a tool like msvc set $CC and $CXX, so that all places where they are used will use the selected tools? I suppose so. > >The order in which directories are searched for include files is often a > >cause of trouble. I think when using a file in double quotes the search > >always looks in the directory of the source file first. When using <> > >that is skipped. My old K&R C book mentions this. > > > >The code apparently uses the current directory instead of the directory > >of the source file. I suppose that's wrong. Please try this patch: > > [...] > > This does appear to have done the trick. I had to trick AAP into > believing that gcc wasn't present to get it to use aap_depend_c(), > though. Setting $CC and $CXX should help: CC = cl CXX = cl May need to use _top.CC and _top.CXX when not in the main recipe. -- hundred-and-one symptoms of being an internet addict: 1 49. You find your computer sexier than your girlfriend /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Thore K. <si...@65...> - 2004-05-06 21:23:51
|
On Thu, 06 May 2004 22:57:46 +0200, Bram Moolenaar <Br...@mo...> wrote: [...] >> When I run AAP in cygwin, AAP defaults to using gcc. I have ":usetool >> MSVC" in my recipe. However, the gcccheck action has cc for $CC and gcc >> for $CXX. I assume this is because the value of these variables is >> substituted when the action is parsed, and not when it is actually >> invoked? >No, they are expanded when the action is invoked. Ah. I was getting confused, since this works as if the variable is expanded when the action is parsed: sourcefiles = Test1/main.cpp :program Test1 : $sourcefiles sourcefiles = Test2/main.cpp :program Test2 : $sourcefiles all : Test1 Test2 Considering that Test1 and Test2 aren't really invoked until we get down to "all", which depends on them, why isn't Test1 built with Test2/main.cpp? That is the last value sourcefiles was set to. I guess what I'm asking is, when is the variable ultimately expanded? >I think the problem simply is that the msvc tool doesn't set $CC or >$CXX. It only sets $MSVC. > >So, should a tool like msvc set $CC and $CXX, so that all places where >they are used will use the selected tools? I suppose so. I would say yes. I see the other tools do the same thing, and I'm not sure why. Perhaps there is a reason for it, but I don't see an explanation. The tools also use undocumented variables like LINKFLAGS to set flags. It seems to me that there should be standard variables for flags to the standard tools. [...] >> This does appear to have done the trick. I had to trick AAP into >> believing that gcc wasn't present to get it to use aap_depend_c(), >> though. >Setting $CC and $CXX should help: > > CC = cl > CXX = cl > >May need to use _top.CC and _top.CXX when not in the main recipe. That worked, but it causes cl.exe to spit out an error message in gcccheck: cl : Command line warning D4002 : ignoring unknown option '/cygdrive/c/DOCUME~1/THOREK~1/LOCALS~1/Temp/tmpe_xfIU.c' cl : Command line error D2003 : missing source filename Isn't there a better way to check if gcc is used than to actually invoke it? Perhaps only run the test if $CC or $CXX is cc, gcc, or g++? Or even let the user explicitly select a method in the recipe. -- Be seeing you. |
From: Bram M. <Br...@mo...> - 2004-05-07 11:22:38
|
Thore Karlsen wrote: > >> When I run AAP in cygwin, AAP defaults to using gcc. I have ":usetool > >> MSVC" in my recipe. However, the gcccheck action has cc for $CC and gcc > >> for $CXX. I assume this is because the value of these variables is > >> substituted when the action is parsed, and not when it is actually > >> invoked? > > >No, they are expanded when the action is invoked. > > Ah. I was getting confused, since this works as if the variable is > expanded when the action is parsed: > > sourcefiles = Test1/main.cpp > :program Test1 : $sourcefiles > > sourcefiles = Test2/main.cpp > :program Test2 : $sourcefiles > > all : Test1 Test2 > > Considering that Test1 and Test2 aren't really invoked until we get down > to "all", which depends on them, why isn't Test1 built with > Test2/main.cpp? That is the last value sourcefiles was set to. > > I guess what I'm asking is, when is the variable ultimately expanded? There are two levels in a recipe: The commands at the toplevel and dependencies are handled when they are encountered. But blocks of commands of actions and dependencies are stored unmodified. They are executed later, expanding variables happens then. > >I think the problem simply is that the msvc tool doesn't set $CC or > >$CXX. It only sets $MSVC. > > > >So, should a tool like msvc set $CC and $CXX, so that all places where > >they are used will use the selected tools? I suppose so. > > I would say yes. I see the other tools do the same thing, and I'm not > sure why. Perhaps there is a reason for it, but I don't see an > explanation. > > The tools also use undocumented variables like LINKFLAGS to set flags. > It seems to me that there should be standard variables for flags to the > standard tools. "it depends". If we have a standard format for $LINKFLAGS then all tools can use it. But if you have a project where some files are compiled with MSVC and some files with MingW, you might have link flags that differ. Switching between the two tools should not result in the variables becoming invalid. The $CC and $CXX are generic: the C and C++ compiler. Thus when selecting a tool I think these variables should be set. But variables specific for one tool should have a name that's only used by that tool. Does this make sense? > >> This does appear to have done the trick. I had to trick AAP into > >> believing that gcc wasn't present to get it to use aap_depend_c(), > >> though. > > >Setting $CC and $CXX should help: > > > > CC = cl > > CXX = cl > > > >May need to use _top.CC and _top.CXX when not in the main recipe. > > That worked, but it causes cl.exe to spit out an error message in > gcccheck: > > cl : Command line warning D4002 : ignoring unknown option > '/cygdrive/c/DOCUME~1/THOREK~1/LOCALS~1/Temp/tmpe_xfIU.c' > cl : Command line error D2003 : missing source filename > > Isn't there a better way to check if gcc is used than to actually invoke > it? Perhaps only run the test if $CC or $CXX is cc, gcc, or g++? Or even > let the user explicitly select a method in the recipe. The error message is disturbing. Skipping the check is probably the only way to avoid it (stderr isn't very well supported on MS-Windows). In the MSVC tool we should be able to tell gcccheck that it doesn't need to try. Making this decision based on the command name is a bit too magic for me. Adding a variable that tells gcccheck to skip the test would be possible. Only problem then is what happens when you switch tools. Well, gcccheck then gets confused anyway, since it's only run once... How about this: - init HASGCC and HASGCCXX to empty - When gcccheck is invoked it only does the test when HASGCC/HASGCCXX is empty. - A tool may change the value of HASGCC and HASGCCXX to skip the test and force a result. - You may set HASGCC and HASGCCXX to empty to have the gcccheck run the test again. A nice effect is that I can remove the hack in test 14 to set $CC to "ignore_this" to use the internal dependency checker. That's an indication we are on the right track. Here is a patch to try out: *** /home/mool/tmp/default.aap Tue Apr 13 20:56:32 2004 --- default.aap Fri May 7 11:20:00 2004 *************** *** 71,104 **** # Use a dependency to avoid checking it more than once. # Use an action to share the code between checking $CC and $CXX. # TODO: handle the situation that $CC is not gcc but "gcc" does exist. ! HASGCC = no ! HASGCCXX = no ! ! gcccheck {virtual} : ! :do gcccheck dummy ! ! gcccheckxx {virtual} : ! :do gcccheck {check_cpp} dummy :action gcccheck default ! MESSAGE = error # Don't echo the commands here ! @try: ! testfile = `tempfname()`.c ! outfile = `tempfname()` ! :eval "#ifdef __GNUC__\nyes;\n#endif\n" >! $testfile ! @if _no.get("check_cpp"): ! :sys $CXX -E $testfile > $outfile ! @else: ! :sys $CC -E $testfile > $outfile ! :cat $outfile | :assign tt ! @if string.find(tt, "yes") >= 0: ! @if _no.get("check_cpp"): ! _recipe.HASGCCXX = yes ! @else: ! _recipe.HASGCC = yes ! @except (StandardError, UserError), e: ! :log Warning: could not test C compiler for being GCC: `str(e)` ! :del {force}{quiet} $testfile $outfile # Depending on the platform, check for available toolchains. --- 71,105 ---- # Use a dependency to avoid checking it more than once. # Use an action to share the code between checking $CC and $CXX. # TODO: handle the situation that $CC is not gcc but "gcc" does exist. ! HASGCC = ! HASGCCXX = :action gcccheck default ! @if _no.get("check_cpp"): ! val = $_recipe.HASGCCXX ! @else: ! val = $_recipe.HASGCC ! @if val == '': ! val = no # default result ! MESSAGE = error # Don't echo the commands here ! @try: ! testfile = `tempfname()`.c ! outfile = `tempfname()` ! :eval "#ifdef __GNUC__\nyes;\n#endif\n" >! $testfile ! @if _no.get("check_cpp"): ! :sys $CXX -E $testfile > $outfile ! @else: ! :sys $CC -E $testfile > $outfile ! :cat $outfile | :assign tt ! @if string.find(tt, "yes") >= 0: ! val = yes ! @except (StandardError, UserError), e: ! :log Warning: could not test C compiler for being GCC: `str(e)` ! :del {force}{quiet} $testfile $outfile ! @if _no.get("check_cpp"): ! _recipe.HASGCCXX = $val ! @else: ! _recipe.HASGCC = $val # Depending on the platform, check for available toolchains. *************** *** 126,137 **** $($)?DEFINE $($)?INCLUDE} c,cpp @if filetype == 'c': ! :update gcccheck usegcc = $HASGCC cc = $CC flags = $CFLAGS @else: ! :update gcccheckxx usegcc = $HASGCCXX cc = $CXX flags = $CXXFLAGS --- 127,140 ---- $($)?DEFINE $($)?INCLUDE} c,cpp @if filetype == 'c': ! @if _no.HASGCC == '': ! :do gcccheck dummy usegcc = $HASGCC cc = $CC flags = $CFLAGS @else: ! @if _no.HASGCCXX == '': ! :do gcccheck {check_cpp} dummy usegcc = $HASGCCXX cc = $CXX flags = $CXXFLAGS -- hundred-and-one symptoms of being an internet addict: 153. You find yourself staring at your "inbox" waiting for new e-mail to arrive. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Thore K. <si...@65...> - 2004-05-10 18:50:22
|
On Fri, 07 May 2004 13:22:24 +0200, Bram Moolenaar <Br...@mo...> wrote: [...] >> >I think the problem simply is that the msvc tool doesn't set $CC or >> >$CXX. It only sets $MSVC. >> > >> >So, should a tool like msvc set $CC and $CXX, so that all places where >> >they are used will use the selected tools? I suppose so. >> >> I would say yes. I see the other tools do the same thing, and I'm not >> sure why. Perhaps there is a reason for it, but I don't see an >> explanation. >> >> The tools also use undocumented variables like LINKFLAGS to set flags. >> It seems to me that there should be standard variables for flags to the >> standard tools. >"it depends". If we have a standard format for $LINKFLAGS then all >tools can use it. But if you have a project where some files are >compiled with MSVC and some files with MingW, you might have link flags >that differ. Switching between the two tools should not result in the >variables becoming invalid. Hmm.. I see what you're saying, but what I'm seeing in the tools files doesn't seem to match it. Currently, MSVC/BCC both use LINKFLAGS, while MingW/GCC use the standard variable LDFLAGS. Different compilers use the standard variable, so they obviously conflict. And if the reason to use LINKFLAGS is to allow several compilers to be used in a recipe, why use the non-standard variable LINKFLAGS for several compilers? Instead of e.g. MSVCLINKFLAGS and BCCLINKFLAGS. >The $CC and $CXX are generic: the C and C++ compiler. Thus when >selecting a tool I think these variables should be set. But variables >specific for one tool should have a name that's only used by that tool. >Does this make sense? That does make sense, but then I wonder why variables like LDFLAGS even exist. I think it's a little confusing the way it is. It's hard to know which flags are used where, unless you go digging through the AAP code. Also, if the linker requires separate flags, why not also the compilers? Why does the MSVC compiler use the standard CPPFLAGS, but not the standard LDFLAGS? Different compilers use different compiler flags, so you couldn't use MingW along with MSVC even if they have different linker flags. And to continue in the same vein: Why use MSVC and MSLINK instead of CC/CXX and LD? You indicated now that CC and CXX should be set to the MS compiler, so is there a need to use MSVC anymore? Was there ever really a need for that? [...] >> cl : Command line warning D4002 : ignoring unknown option >> '/cygdrive/c/DOCUME~1/THOREK~1/LOCALS~1/Temp/tmpe_xfIU.c' >> cl : Command line error D2003 : missing source filename >> >> Isn't there a better way to check if gcc is used than to actually invoke >> it? Perhaps only run the test if $CC or $CXX is cc, gcc, or g++? Or even >> let the user explicitly select a method in the recipe. >The error message is disturbing. Skipping the check is probably the >only way to avoid it (stderr isn't very well supported on MS-Windows). > >In the MSVC tool we should be able to tell gcccheck that it doesn't need >to try. I agree. >Making this decision based on the command name is a bit too >magic for me. Adding a variable that tells gcccheck to skip the test >would be possible. Only problem then is what happens when you switch >tools. Well, gcccheck then gets confused anyway, since it's only run >once... > >How about this: >- init HASGCC and HASGCCXX to empty >- When gcccheck is invoked it only does the test when HASGCC/HASGCCXX is > empty. >- A tool may change the value of HASGCC and HASGCCXX to skip the test > and force a result. >- You may set HASGCC and HASGCCXX to empty to have the gcccheck run the > test again. > >A nice effect is that I can remove the hack in test 14 to set $CC to >"ignore_this" to use the internal dependency checker. That's an >indication we are on the right track. > >Here is a patch to try out: [...] Works like a charm! Along with the changes I made in msvc.py to set HASGCC/HASGCCXX to "no". -- Be seeing you. |
From: Bram M. <Br...@mo...> - 2004-05-10 20:09:24
|
Thore Karlsen wrote: > >"it depends". If we have a standard format for $LINKFLAGS then all > >tools can use it. But if you have a project where some files are > >compiled with MSVC and some files with MingW, you might have link flags > >that differ. Switching between the two tools should not result in the > >variables becoming invalid. > > Hmm.. I see what you're saying, but what I'm seeing in the tools files > doesn't seem to match it. Currently, MSVC/BCC both use LINKFLAGS, while > MingW/GCC use the standard variable LDFLAGS. > > Different compilers use the standard variable, so they obviously > conflict. And if the reason to use LINKFLAGS is to allow several > compilers to be used in a recipe, why use the non-standard variable > LINKFLAGS for several compilers? Instead of e.g. MSVCLINKFLAGS and > BCCLINKFLAGS. True, this problem already exists. Perhaps we should say that $LDFLAGS can be used for arguments that the "standard Unix cc" understands, and a compiler-specific variable should be used for compiler-specific arguments. > >The $CC and $CXX are generic: the C and C++ compiler. Thus when > >selecting a tool I think these variables should be set. But variables > >specific for one tool should have a name that's only used by that tool. > >Does this make sense? > > That does make sense, but then I wonder why variables like LDFLAGS even > exist. I think it's a little confusing the way it is. It's hard to know > which flags are used where, unless you go digging through the AAP code. Yes, making something portable _is_ complicated. But we can try to find the simplest solution. > Also, if the linker requires separate flags, why not also the compilers? > Why does the MSVC compiler use the standard CPPFLAGS, but not the > standard LDFLAGS? Different compilers use different compiler flags, so > you couldn't use MingW along with MSVC even if they have different > linker flags. True. It appears there is no good naming system yet. > And to continue in the same vein: Why use MSVC and MSLINK instead of > CC/CXX and LD? You indicated now that CC and CXX should be set to the MS > compiler, so is there a need to use MSVC anymore? Was there ever really > a need for that? The idea is that you can set $MSVC to where your MS compiler is, while you also use gcc. Then ":usetool" can be used switch between the two. But it appears this isn't consistent yet. Again, perhaps a good approach is to use $CC and $CXX for compilers that use "normal Unix cc" arguments. I think that's the only de facto standard for compilers that exists. Gcc also uses that, although it has many extensions. Many compilers do have equivalents for the "standard cc" flags. The could could translate them. This already is the intention for the "$INCLUDE" and "$DEFINE variables. We could add more variables like that. Now that you tested the changes to the tools I'll check in a new version. That is going to be version 1.065. Please try it out when it's ready. -- hundred-and-one symptoms of being an internet addict: 228. You spend Saturday night making the counter on your home page pass that 2000 mark. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |