Thread: [Ctags-devel] Developers Quick-Start
Brought to you by:
dhiebert
From: Darren H. <dhi...@us...> - 2006-09-22 03:36:02
|
The ctags source archive has what might be regarded as some peculiarities in its makeup to support how I have managed things up until now. While these are certainly open to change to support more developers, I must document at least some of these for now to get our new developers started. Here are a few: 1. The steps to perform after doing an "svn checkout" are: $ autoheader $ ./configure --enable-maintainer-mode 2. The maintainer makefile, which is linked to by "Makefile" when following the above steps, has two primary targets: a. "dctags" (the default), which builds a version of the binary with debugging and development support built-in (e.g. the -D option, whose argument is a bit-field). This is built up by compiling the source files to .od extensions so that they can co-exist with the .o files below. b. "ctags", which is a fully optimized version of the binary for performance testing, compiled up from .o files. c. "test", which runs the files in the Test directory and a linux kernel source tree (if found) through both the "ctags" binary (above) and a "ctags.ref" binary in the ctags directory, which is assumed to be the most recent "base" version of ctags prior to the set of source changes in process. The output from this test target is zero or more diff files between the tag files generated various ways using the two binaries. This allows one to examine all changes in output and determine whether the changes are for the better. If so, then the current ctags binary can become the new ctags.ref base version for future checks. -- Darren Hiebert http://darrenhiebert.com http://ctags.sourceforge.net |
From: David F. <fis...@ia...> - 2006-09-23 02:23:06
|
> -----Original Message----- > From: cta...@li... > [mailto:cta...@li...] On Behalf > Of Darren Hiebert > Sent: Thursday, September 21, 2006 11:36 PM > To: cta...@li... > Subject: [Ctags-devel] Developers Quick-Start > > The ctags source archive has what might be regarded as some > peculiarities in its makeup to support how I have managed > things up until now. While these are certainly open to change > to support more developers, I must document at least some of > these for now to get our new developers started. > > Here are a few: > > 1. The steps to perform after doing an "svn checkout" are: > > $ autoheader > $ ./configure --enable-maintainer-mode How can you run this on the Windows platforms? > 2. The maintainer makefile, which is linked to by "Makefile" > when following the above steps, has two primary targets: > > a. "dctags" (the default), which builds a version of > the binary with debugging and development support built-in > (e.g. the -D option, whose argument is a bit-field). This is > built up by compiling the source files to .od extensions so > that they can co-exist with the .o files below. I tried running some variations of this: 100 22:12:56 c:\opensrc\ctags_svn>nmake -f maintainer.mak testing Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. maintainer.mak(65) : fatal error U1036: syntax error : too many names to left of '=' Stop. 100 22:20:43 c:\opensrc\ctags_svn>nmake -f maintainer.mak dctags Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. maintainer.mak(65) : fatal error U1036: syntax error : too many names to left of '=' Stop. > c. "test", which runs the files in the Test directory > and a linux kernel source tree (if found) through both the > "ctags" binary (above) and a "ctags.ref" binary in the ctags > directory, which is assumed to be the most recent "base" > version of ctags prior to the set of source changes in process. > The output from this test target is zero or more diff files > between the tag files generated various ways using the two > binaries. This allows one to examine all changes in output > and determine whether the changes are for the better. If so, > then the current ctags binary can become the new ctags.ref > base version for future checks. Couldn't figure out how to run this test suite either. I can build everything with: nmake -f mk_mvc.mak ctags.exe nmake -f mk_mvc.mak dctags.exe Any hints? Thanks, Dave |
From: Darren H. <dhi...@us...> - 2006-09-24 04:48:26
|
On Friday 22 September 2006 21:22, David Fishburn wrote: > > -----Original Message----- > > From: cta...@li... > > [mailto:cta...@li...] On Behalf > > Of Darren Hiebert > > Sent: Thursday, September 21, 2006 11:36 PM > > To: cta...@li... > > Subject: [Ctags-devel] Developers Quick-Start > > > > The ctags source archive has what might be regarded as some > > peculiarities in its makeup to support how I have managed > > things up until now. While these are certainly open to change > > to support more developers, I must document at least some of > > these for now to get our new developers started. > > > > Here are a few: > > > > 1. The steps to perform after doing an "svn checkout" are: > > > > $ autoheader > > $ ./configure --enable-maintainer-mode > > How can you run this on the Windows platforms? You can't easily. I never did development on Windows--I used Linux only. My set up was only to allow for Windows compilation. > > 2. The maintainer makefile, which is linked to by "Makefile" > > when following the above steps, has two primary targets: > > > > a. "dctags" (the default), which builds a version of > > the binary with debugging and development support built-in > > (e.g. the -D option, whose argument is a bit-field). This is > > built up by compiling the source files to .od extensions so > > that they can co-exist with the .o files below. > > I tried running some variations of this: > > 100 22:12:56 c:\opensrc\ctags_svn>nmake -f maintainer.mak testing > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > maintainer.mak(65) : fatal error U1036: syntax error : too many names to > left of '=' > Stop. > > 100 22:20:43 c:\opensrc\ctags_svn>nmake -f maintainer.mak dctags > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > maintainer.mak(65) : fatal error U1036: syntax error : too many names to > left of '=' > Stop. Nmake isn't going to work because the maintainer.mak is GNU Make specific at present. > > c. "test", which runs the files in the Test directory > > and a linux kernel source tree (if found) through both the > > "ctags" binary (above) and a "ctags.ref" binary in the ctags > > directory, which is assumed to be the most recent "base" > > version of ctags prior to the set of source changes in process. > > The output from this test target is zero or more diff files > > between the tag files generated various ways using the two > > binaries. This allows one to examine all changes in output > > and determine whether the changes are for the better. If so, > > then the current ctags binary can become the new ctags.ref > > base version for future checks. > > Couldn't figure out how to run this test suite either. We'll have to work out a portable way. I anticipated that these infrastructure issues would take some work. -- Darren Hiebert http://darrenhiebert.com -- Darren Hiebert http://darrenhiebert.com http://ctags.sourceforge.net |
From: Elliott H. <en...@je...> - 2006-09-24 04:55:00
|
On 2006-09-23, at 21:48, Darren Hiebert wrote: > On Friday 22 September 2006 21:22, David Fishburn wrote: >> How can you run this on the Windows platforms? > > You can't easily. I never did development on Windows--I used Linux > only. My > set up was only to allow for Windows compilation. i don't use Windows either, but Cygwin might work. there's Bash, there's GNU make, there's diff(1). --elliott |
From: Elliott H. <en...@je...> - 2006-09-24 04:31:12
|
On 2006-09-21, at 20:35, Darren Hiebert wrote: > 1. The steps to perform after doing an "svn checkout" are: > > $ autoheader do you mean "autoconf" instead? "autoheader" doesn't generate me a "./ configure" to go on to the next step with. i was running autoheader 2.59, on Ubuntu 6.06. > b. "ctags", which is a fully optimized version of the binary for > performance > testing, compiled up from .o files. "maintainer.mak" includes "-march=i686", which prevents this from building on Mac OS or 64-bit Linux. > c. "test", which runs the files in the Test directory and a linux > kernel > source tree (if found) through both the "ctags" binary (above) and > a "ctags.ref" binary in the ctags directory, which is assumed to be > the most > recent "base" version of ctags prior to the set of source changes > in process. this also doesn't work; the makefile actually assumes that "ctags.ref" is on the user's path. if i modify my path, most of the tests work, but the Eiffel tests fail for lack of a /library directory. --elliott |
From: Darren H. <dhi...@us...> - 2006-09-24 04:43:26
|
On Saturday 23 September 2006 23:31, Elliott Hughes wrote: > On 2006-09-21, at 20:35, Darren Hiebert wrote: > > 1. The steps to perform after doing an "svn checkout" are: > > > > $ autoheader > > do you mean "autoconf" instead? "autoheader" doesn't generate me a "./ > configure" to go on to the next step with. After I sent this, I realized I forgot a step. This is what was intended: $ autoheader $ autoconf $ ./configure --enable-maintainer-mode > > b. "ctags", which is a fully optimized version of the binary for > > performance > > testing, compiled up from .o files. > > "maintainer.mak" includes "-march=i686", which prevents this from > building on Mac OS or 64-bit Linux. Obviously, this was particular to my setup and approach and will have to be generalized to be useful to others. As a work-around, I suggest removing this option. > > c. "test", which runs the files in the Test directory and a linux > > kernel > > source tree (if found) through both the "ctags" binary (above) and > > a "ctags.ref" binary in the ctags directory, which is assumed to be > > the most > > recent "base" version of ctags prior to the set of source changes > > in process. > > this also doesn't work; the makefile actually assumes that > "ctags.ref" is on the user's path. if i modify my path, most of the > tests work, but the Eiffel tests fail for lack of a /library directory. Yes, I also ran my tests over my Eiffel library directory. I need to make that conditional, as I did for the Linux kernel source directory. When I posted these instructions, it was only to document how it is currently set up. I knew that it would have to change. But I wanted to at least let people know the steps that were expected or previously used. I just wanted to get folks started. -- Darren Hiebert http://darrenhiebert.com http://ctags.sourceforge.net |
From: David F. <fis...@ia...> - 2006-10-13 20:46:45
|
> -----Original Message----- > From: cta...@li... > [mailto:cta...@li...] On Behalf > Of Darren Hiebert > Sent: Thursday, September 21, 2006 11:36 PM > To: cta...@li... > Subject: [Ctags-devel] Developers Quick-Start > > The ctags source archive has what might be regarded as some > peculiarities in its makeup to support how I have managed > things up until now. While these are certainly open to change > to support more developers, I must document at least some of > these for now to get our new developers started. > > Here are a few: > > 1. The steps to perform after doing an "svn checkout" are: > > $ autoheader > $ ./configure --enable-maintainer-mode > > 2. The maintainer makefile, which is linked to by "Makefile" > when following the above steps, has two primary targets: > > a. "dctags" (the default), which builds a version of > the binary with debugging and development support built-in > (e.g. the -D option, whose argument is a bit-field). This is > built up by compiling the source files to .od extensions so > that they can co-exist with the .o files below. > > b. "ctags", which is a fully optimized version of the > binary for performance testing, compiled up from .o files. > > c. "test", which runs the files in the Test directory > and a linux kernel source tree (if found) through both the > "ctags" binary (above) and a "ctags.ref" binary in the ctags > directory, which is assumed to be the most recent "base" > version of ctags prior to the set of source changes in process. > The output from this test target is zero or more diff files > between the tag files generated various ways using the two > binaries. This allows one to examine all changes in output > and determine whether the changes are for the better. If so, > then the current ctags binary can become the new ctags.ref > base version for future checks. [ctags_svn]# make test make: *** No rule to make target `ctags.ref', needed by `test.include'. Stop. make ctags make dctags Both work fine. Is there something else I need to do here? Thanks, Dave |
From: Elliott H. <en...@je...> - 2006-10-13 21:40:54
|
On Fri, October 13, 2006 13:46, David Fishburn wrote: > [ctags_svn]# make test > make: *** No rule to make target `ctags.ref', needed by `test.include'. > Stop. > > Is there something else I need to do here? yes. i thought i mentioned this in my original "didn't quite work for me" mail: you need to copy a known-good copy of "ctags" or "dctags" to "ctags.ref" (as in "reference"). this is the one that your current binary will be compared to when you "make test". -- Elliott Hughes, http://www.jessies.org/~enh/ |
From: Darren H. <dhi...@us...> - 2006-10-13 23:07:24
|
On Friday 13 October 2006 16:40, Elliott Hughes wrote: > On Fri, October 13, 2006 13:46, David Fishburn wrote: > > [ctags_svn]# make test > > make: *** No rule to make target `ctags.ref', needed by `test.include'. > > Stop. > > > > Is there something else I need to do here? > > yes. i thought i mentioned this in my original "didn't quite work for me" > mail: you need to copy a known-good copy of "ctags" or "dctags" to > "ctags.ref" (as in "reference"). this is the one that your current binary > will be compared to when you "make test". Elliot is correct. Testing a ctags executable being modified means testing that it generates "correct" output. However, the problem is that we don't have a set of "correct" ( i.e. perfect) output to begin with. Therefore, I setup each of the testing targets in the testing.mak makefile to compare an "after" tag file (generated by the modified ctags executable) against a baseline "before" tag file (generated by some reference executable: ctags.ref). If the two tag files do not match, a diff file is created for the developer to examine and determine if the "after" make file is "better" in his judgement (i.e. its contains tags missing from the baseline that should be there, and doesn't contain tags in the baseline that shouldn't have been there). If the developer determines that the new tag file(s) are better than the previous one(s), the developer copies the current executable to ctags.ref for checking future changes. The testing.mak makefile (included into maintainer.mak, which is linked by Makefile if you configure with --enable-maintainer-mode) contains the following targets: test.include Tests for whether tags are included or not. Turns off all extension fields in order to limit differences to only lines included or not. test.fields Tests for changes to extension fields. test.extra Tests for changes to extra tags controlled by --extra option. test.linedir Sets options to test handling of line directives. test.etags Tests etags output. test.eiffel Tests tags found in Eiffel code, if available. test.linux Tests tags found in Linux kernel, if available. Mismatch reports are going to be redundant in certain cases. Clearly, if test.include finds differences, test.fields will also, even if no changes were made to extension fields. So one has to understand what is being reported and know what to ignore. Most of you will only be interested in test.include and test.fields (but only if your parser supports them). I am always open to suggestions as to how I might improve the testing support. I understand that the way I have done it is somewhat quirky. Darren -- Darren Hiebert http://darrenhiebert.com http://ctags.sourceforge.net |