Commit | Line | Data |
---|---|---|
a84251b0 LC |
1 | -*-text-*- |
2 | Guile Hacking Guide | |
b226295a | 3 | Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2008 Free software Foundation, Inc. |
a84251b0 LC |
4 | |
5 | Permission is granted to anyone to make or distribute verbatim copies | |
6 | of this document as received, in any medium, provided that the | |
7 | copyright notice and permission notice are preserved, | |
8 | and that the distributor grants the recipient permission | |
9 | for further redistribution as permitted by this notice. | |
10 | ||
11 | Permission is granted to distribute modified versions | |
12 | of this document, or of portions of it, | |
13 | under the above conditions, provided also that they | |
14 | carry prominent notices stating who last changed them, | |
15 | and that any new or changed statements about the activities | |
16 | of the Free Software Foundation are approved by the Foundation. | |
17 | ||
18 | ||
19 | What to Hack ========================================================= | |
20 | ||
21 | You can hack whatever you want, thank GNU. | |
22 | ||
23 | However, to see what others have indicated as their interest (and avoid | |
24 | potential wasteful duplication of effort), see file TODO. Note that | |
25 | the version you find may be out of date; a CVS checkout is recommended: | |
26 | see below for details (see also the files ANON-CVS and SNAPSHOTS). | |
27 | ||
28 | It's also a good idea to join the guile-devel@gnu.org mailing list. | |
29 | See http://www.gnu.org/software/guile/mail/mail.html for more info. | |
30 | ||
31 | ||
32 | Hacking It Yourself ================================================== | |
33 | ||
34 | When Guile is obtained from CVS, a few extra steps must be taken | |
35 | before the usual configure, make, make install. You will need to have | |
36 | up-to-date versions of the tools listed below, correctly installed. | |
37 | i.e., they must be found in the current PATH and not shadowed or | |
38 | otherwise broken by files left behind from other versions. | |
39 | ||
40 | "up-to-date" means the latest released versions at the time that Guile | |
41 | was obtained from CVS. Sometimes older or newer versions will work. | |
42 | (See below for versions to avoid.) | |
43 | ||
44 | Then you must run the autogen.sh script, as described below. | |
45 | ||
46 | In case of problems, it may be worth getting a fresh copy of Guile | |
47 | from CVS: synchronisation problems have been known to occur | |
48 | occasionally. | |
49 | ||
50 | The same procedure can be used to regenerate the files in released | |
51 | versions of Guile. In that case the headers of the original generated | |
52 | files (e.g., configure, Makefile.in, ltmain.sh) can be used to | |
53 | identify which tool versions may be required. | |
54 | ||
55 | Autoconf --- a system for automatically generating `configure' | |
56 | scripts from templates which list the non-portable features a | |
57 | program would like to use. Available in | |
58 | "ftp://ftp.gnu.org/pub/gnu/autoconf" | |
59 | ||
60 | Automake --- a system for automatically generating Makefiles that | |
61 | conform to the (rather Byzantine) GNU coding standards. The | |
62 | nice thing is that it takes care of hairy targets like 'make | |
63 | dist' and 'make distclean', and automatically generates | |
64 | Makefile dependencies. Automake is available in | |
65 | "ftp://ftp.gnu.org/pub/gnu/automake" | |
66 | ||
67 | libtool --- a system for managing the zillion hairy options needed | |
68 | on various systems to produce shared libraries. Available in | |
d4a00708 NJ |
69 | "ftp://ftp.gnu.org/pub/gnu/libtool". Version 1.5.26 (or |
70 | later) is needed for correct AIX support. | |
a84251b0 LC |
71 | |
72 | gettext --- a system for rigging a program so that it can output its | |
73 | messages in the local tongue. Guile presently only exports | |
74 | the gettext functionality to Scheme, it does not use it | |
75 | itself. | |
76 | ||
77 | flex --- a scanner generator. It's probably not essential to have the | |
78 | latest version. | |
79 | ||
80 | One false move and you will be lost in a little maze of automatically | |
81 | generated files, all different. | |
82 | ||
83 | Here is the authoritative list of tool/version/platform tuples that | |
84 | have been known to cause problems, and a short description of the problem. | |
85 | ||
86 | - automake 1.4 adds extraneous rules to the top-level Makefile if | |
87 | you specify specific Makefiles to rebuild on the command line. | |
88 | ||
89 | - automake 1.4-p4 (debian "1:1.4-p4-1.1") all platforms | |
90 | automake "include" facility does not recognize filenames w/ "-". | |
91 | ||
92 | - libtool 1.4 uses acconfig.h, which is deprecated by newest autoconf | |
93 | (which constructs the equivalent through 3rd arg of AC_DEFINE forms). | |
94 | ||
95 | - autoreconf from autoconf prior to 2.59 will run gettextize, which | |
96 | will mess up the Guile tree. | |
97 | ||
98 | - (add here.) | |
99 | ||
100 | ||
101 | Sample GDB Initialization File========================================= | |
102 | ||
103 | Here is a sample .gdbinit posted by Bill Schottstaedt (modified to | |
104 | use `set' instead of `call' in some places): | |
105 | ||
106 | define gp | |
107 | set gdb_print($arg0) | |
108 | print gdb_output | |
109 | end | |
110 | document gp | |
111 | Executes (object->string arg) | |
112 | end | |
113 | ||
114 | define ge | |
115 | call gdb_read($arg0) | |
116 | call gdb_eval(gdb_result) | |
117 | set gdb_print(gdb_result) | |
118 | print gdb_output | |
119 | end | |
120 | document ge | |
121 | Executes (print (eval (read arg))): ge "(+ 1 2)" => 3 | |
122 | end | |
123 | ||
124 | define gh | |
125 | call g_help(scm_str2symbol($arg0), 20) | |
126 | set gdb_print($1) | |
127 | print gdb_output | |
128 | end | |
129 | document gh | |
130 | Prints help string for arg: gh "enved-target" | |
131 | end | |
132 | ||
133 | Bill further writes: | |
134 | ||
135 | so in gdb if you see something useless like: | |
136 | ||
137 | #32 0x081ae8f4 in scm_primitive_load (filename=1112137128) at load.c:129 | |
138 | ||
139 | You can get the file name with gp: | |
140 | ||
141 | (gdb) gp 1112137128 | |
142 | $1 = 0x40853fac "\"/home/bil/test/share/guile/1.5.0/ice-9/session.scm\"" | |
143 | ||
144 | ||
145 | Contributing Your Changes ============================================ | |
146 | ||
147 | - If you have put together a change that meets the coding standards | |
148 | described below, we encourage you to submit it to Guile. The best | |
149 | place to post it is guile-devel@gnu.org. Please don't send it | |
150 | directly to me; I often don't have time to look things over. If you | |
151 | have tested your change, then you don't need to be shy. | |
152 | ||
153 | - Please submit patches using either context or unified diffs (diff -c | |
154 | or diff -u). Don't include a patch for ChangeLog; such patches don't | |
155 | apply cleanly, since we've probably changed the top of ChangeLog too. | |
156 | Instead, provide the unaltered text at the top of your patch. | |
157 | ||
158 | - For proper credit, also make sure you update the AUTHORS file | |
159 | (for new files for which you've assigned copyright to the FSF), or | |
160 | the THANKS file (for everything else). | |
161 | ||
162 | Please don't include patches for generated files like configure, | |
163 | aclocal.m4, or any Makefile.in. Such patches are often large, and | |
164 | we're just going to regenerate those files anyway. | |
165 | ||
166 | ||
167 | CVS conventions ====================================================== | |
168 | ||
169 | - We use CVS to manage the Guile sources. The repository lives on | |
170 | subversions.gnu.org, in /cvs; you will need an | |
171 | account on that machine to access the repository. Also, for security | |
172 | reasons, subversions presently only supports CVS connections via the SSH | |
173 | protocol, so you must first install the SSH client. Then, you should | |
174 | set your CVS_RSH environment variable to ssh, and use the following as | |
175 | your CVS root: | |
176 | ||
177 | :ext:USER@subversions.gnu.org:/cvs | |
178 | ||
179 | Either set your CVSROOT environment variable to that, or give it as | |
180 | the value of the global -d option to CVS when you check out a working | |
181 | directory. | |
182 | ||
183 | For more information on SSH, see http://www.openssh.com. | |
184 | ||
185 | The Guile sources live in several modules: | |
186 | ||
187 | - guile-core --- the interpreter, QuickThreads, and ice-9 | |
188 | - guile-tcltk --- the Guile/Tk interface | |
189 | - guile-tk --- the new Guile/Tk interface, based on STk's modified Tk | |
190 | - guile-rgx-ctax --- the Guile/Rx interface, and the ctax implementation | |
191 | - guile-scsh --- the port of SCSH to guile, talk to Gary Houston | |
192 | - guile-www --- A Guile module for making HTTP requests. | |
193 | - guile-statprof --- an experimental statistical profiler. | |
194 | ||
195 | There is a mailing list for CVS commit messages; see README for details. | |
196 | ||
197 | - The guile-core tree is now versioned similarly to the Linux kernel. | |
198 | Guile now always uses three numbers to represent the version, | |
199 | i.e. "1.6.5". The first number, 1, is the major version number, the | |
200 | second number, 6, is the minor version number, and the third number, | |
201 | 5, is the micro version number. Changes in major version number | |
202 | indicate major changes in Guile. | |
203 | ||
204 | Minor version numbers that are even denote stable releases, and odd | |
205 | minor version numbers denote development versions (which may be | |
206 | unstable). The micro version number indicates a minor sub-revision of | |
207 | a given MAJOR.MINOR release. | |
208 | ||
209 | - A default CVS checkout will get the current unstable development | |
210 | tree. However, for each stable release, a CVS branch is created so | |
211 | that release (and ongoing maintenance) of the stable version can | |
212 | proceed independent of the development of the next unstable version. | |
213 | To check out a particular stable branch, you just need to specify "-r | |
214 | branch_release-X-Y" to your CVS checkout command (or to any update). | |
215 | For example, if you wanted to check out the 1.6 stable branch, you | |
216 | would specify "-r branch_release-1-6". | |
217 | ||
218 | So, for example, during a normal development cycle, work will proceed | |
219 | on an unstable version, say 1.5.X, until it is decided that it's time | |
220 | for a stable release. At that point, a branch named | |
221 | branch_release-1-6 will be created, and the version numbers on the | |
222 | HEAD of the CVS tree (the trunk, i.e. what you get by default), will | |
223 | be changed to reflect the new unstable version 1.7.X. Then unstable | |
224 | development will proceed on the unstable version, while the stable | |
225 | 1.5.X branch is fixed up for the eventual 1.6.0 release. | |
226 | ||
227 | Anytime you want to yank an existing checked out tree to the stable | |
228 | branch, you can run a command like this: | |
229 | ||
230 | cvs -z3 update -r branch_release-1-6 -Pd | |
231 | ||
232 | This will yank the working directory over on to the stable release | |
233 | branch. Note that this directory will track that branch from then on | |
234 | unless you do something to yank it back to the main (unstable) trunk. | |
235 | ||
236 | To go back to the unstable branch, you can use | |
237 | ||
238 | cvs -z3 update -A -Pd | |
239 | ||
240 | Note that in either case, you should probably make sure you've | |
241 | commited or removed all local changes before running the commands or | |
242 | you're likely to have some unexpected results. | |
243 | ||
244 | Finally note that one approach, should you need to work on both | |
245 | branches, is to keep two trees checked out, one stable, the other | |
246 | unstable and you can work in whichever is appropriate. | |
247 | ||
248 | To save some initial bandwidth, you can check out either the stable | |
249 | tree or the unstable tree, and then do something like this: | |
250 | ||
251 | cp -a core-unstable core-1.5 | |
252 | cd core-1.5 | |
253 | cvs -z3 update -r branch_release-1-6 -Pd | |
254 | ||
255 | - The stable and unstable CVS trees are distinct, and no changes will | |
256 | automatically propagate between them. If you make changes that need | |
257 | to show up both places, you'll need to apply the changes both places. | |
258 | You *might* be able to do this with a cvs command, but often you'll | |
259 | probably need to apply the changes by hand or risk migrating | |
260 | superfluous modifications between the two versions. This is | |
261 | particularly important when moving a change from the unstable branch | |
262 | to the stable branch. | |
263 | ||
264 | - In general, please don't be adventurous with the stable branch. We | |
265 | mostly want bugfixes, documentation improvements, build improvements, | |
266 | etc., though exceptions will doubtless exist. | |
267 | ||
268 | - There are a few CVS tagging conventions which follow the Scheme | |
269 | convention that dashes are used to separate words within a single | |
270 | symbol, and so dashes bind more tightly than underscores. This means | |
271 | that foo-bar_baz-bax indicates that foo-bar is somehow separate from | |
272 | baz-bax. The conventions are as follows: | |
273 | ||
274 | Branch root tags: | |
275 | ----------------- | |
276 | anytime just before you create a branch it's a good | |
277 | idea to create a normal tag so that you can refer to the branch point | |
278 | on the main trunk as well as on the branch. So please use a tag of | |
279 | the form | |
280 | ||
281 | branch-root-release-1-X | |
282 | ||
283 | or more generally, for other non-release branches: | |
284 | ||
285 | branch-root_FOO | |
286 | ||
287 | Branch tags: | |
288 | ------------ | |
289 | for the branch tag itself please use | |
290 | ||
291 | branch_release-1-6 | |
292 | ||
293 | or more generally, for other non-release branches: | |
294 | ||
295 | branch_FOO | |
296 | ||
297 | Merge tags: | |
298 | ----------- | |
299 | Whenever you're merging a branch back into the trunk (or into another | |
300 | branch repeatedly) you need to tag the branch each time you merge. If | |
301 | you don't do that, you won't be able to merge repeatedly without | |
302 | possibly tedious conflicts. For those tags, we suggest: | |
303 | ||
304 | branch-merge_SOME-FOO_to_SOME-BAR_1 | |
305 | branch-merge_SOME-FOO_to_SOME-BAR_2 | |
306 | .. | |
307 | ||
308 | As an example, SOME-BAR might be trunk, or even perhaps another branch | |
309 | like branch-mvo-super-fixes :> | |
310 | ||
311 | More mundanely, you might have | |
312 | ||
313 | branch-merge_release-1-6_to_trunk_1 | |
314 | ||
315 | (Merging the stable branch to the trunk like this | |
316 | will probably be much more common, when it happens, than the | |
317 | reverse for the reasons mentioned above. | |
318 | ||
319 | Release tags: | |
320 | ------------- | |
321 | When releasing a new version of guile, please use: | |
322 | ||
323 | release_X-Y-Z | |
324 | ||
325 | i.e. | |
326 | ||
327 | release_1-6-0 | |
328 | ||
329 | - If you hack on a stable branch, please apply any relevant patches or | |
330 | fixes to the current unstable version (the main CVS trunk) as well. | |
331 | Similarly, please back-port any important fixes to the unstable CVS | |
332 | tree to the current stable branch. | |
333 | ||
334 | - We check Makefile.am and configure.in files into CVS, but the | |
335 | "autogen.sh" script must be run from the top-level to generate the | |
336 | actual "configure" script that then must be run to create the various | |
337 | Makefile-s to build guile. The general rule is that you should be able | |
338 | to check out a working directory of Guile from CVS, and then type | |
339 | "./autogen.sh", then "configure", and finally "make". No | |
340 | automatically generated files should be checked into the CVS | |
341 | repository. | |
342 | ||
343 | - The .cvsignore file is contained in the repository, to provide a | |
344 | reasonable list of auto-generated files that should not be checked in. | |
345 | This, however, prohibits one from having local additions to the | |
346 | .cvsignore file (yes, you can modify it and never check it in, but | |
347 | that doesn't seem to be a good solution to me). To get around this | |
348 | problem, you might want to patch your cvs program so that it uses a | |
349 | .cvsignore-local file (say) instead of the one from the repository. A | |
350 | patch for this can be found at the very end of this file. | |
351 | ||
352 | - (Automake 1.4 only) Be sure to run automake at the top of the tree | |
353 | with no arguments. Do not use `automake Makefile' to regenerate | |
354 | specific Makefile.in files, and do not trust the Makefile rules to | |
355 | rebuild them when they are out of date. Automake 1.4 will add | |
356 | extraneous rules to the top-level Makefile if you specify specific | |
357 | Makefiles to rebuild on the command line. Running the command | |
358 | `autoreconf --force' should take care of everything correctly. | |
359 | ||
360 | - Make sure your changes compile and work, at least on your own | |
361 | machine, before checking them into the main branch of the Guile | |
362 | repository. A good way for testing this is to run "make distcheck". | |
363 | If you really need to check in untested changes, make a branch. | |
364 | ||
365 | - Include each log entry in both the ChangeLog and in the CVS logs. | |
366 | If you're using Emacs, the pcl-cvs interface to CVS has features to | |
367 | make this easier; it checks the ChangeLog, and generates good default | |
368 | CVS log entries from that. | |
369 | ||
370 | ||
371 | Coding standards ===================================================== | |
372 | ||
373 | - Before contributing larger amounts of code to Guile, please read the | |
374 | documents in `guile-core/devel/policy' in the CVS source tree. | |
375 | ||
376 | - As for any part of Project GNU, changes to Guile should follow the | |
377 | GNU coding standards. The standards are available via anonymous FTP | |
378 | from prep.ai.mit.edu, as /pub/gnu/standards/standards.texi and | |
379 | make-stds.texi. | |
380 | ||
381 | - The Guile tree should compile without warnings under the following | |
382 | GCC switches, which are the default in the current configure script: | |
383 | ||
384 | -O2 -Wall -Wpointer-arith -Wmissing-prototypes | |
385 | ||
386 | To make sure of this, you can use the --enable-error-on-warning option | |
387 | to configure. This option will make GCC fail if it hits a warning. | |
388 | ||
389 | Note that the warnings generated vary from one version of GCC to the | |
390 | next, and from one architecture to the next (apparently). To provide | |
391 | a concrete common standard, Guile should compile without warnings from | |
392 | GCC 2.7.2.3 in a Red Hat 5.2 i386 Linux machine. Furthermore, each | |
393 | developer should pursue any additional warnings noted by on their | |
394 | compiler. This means that people using more stringent compilers will | |
395 | have more work to do, and assures that everyone won't switch to the | |
396 | most lenient compiler they can find. :) | |
397 | ||
398 | Note also that EGCS (as of November 3 1998) doesn't handle the | |
399 | `noreturn' attribute properly, so it doesn't understand that functions | |
400 | like scm_error won't return. This may lead to some silly warnings | |
401 | about uninitialized variables. You should look into these warnings to | |
402 | make sure they are indeed spurious, but you needn't correct warnings | |
403 | caused by this EGCS bug. | |
404 | ||
405 | - If you add code which uses functions or other features that are not | |
406 | entirely portable, please make sure the rest of Guile will still | |
407 | function properly on systems where they are missing. This usually | |
408 | entails adding a test to configure.in, and then adding #ifdefs to your | |
409 | code to disable it if the system's features are missing. | |
410 | ||
411 | - The normal way of removing a function, macro or variable is to mark | |
412 | it as "deprecated", keep it for a while, and remove it in a later | |
413 | release. If a function or macro is marked as "deprecated" it | |
414 | indicates that people shouldn't use it in new programs, and should try | |
415 | to remove it in old. Make sure that an alternative exists unless it | |
416 | is our purpose to remove functionality. Don't deprecate definitions | |
417 | if it is unclear when they will be removed. (This is to ensure that a | |
418 | valid way of implementing some functionality always exists.) | |
419 | ||
420 | When deprecating a definition, always follow this procedure: | |
421 | ||
422 | 1. Mark the definition using | |
423 | ||
424 | #if (SCM_DEBUG_DEPRECATED == 0) | |
425 | ... | |
426 | #endif | |
427 | ||
428 | or, for Scheme code, wrap it using | |
429 | ||
430 | (begin-deprecated | |
431 | ...) | |
432 | ||
433 | 2. Make the deprecated code issue a warning when it is used, by using | |
434 | scm_c_issue_deprecation_warning (in C) or issue-deprecation-warning | |
435 | (in Scheme). | |
436 | ||
437 | 3. Write a comment at the definition explaining how a programmer can | |
438 | manage without the deprecated definition. | |
439 | ||
440 | 4. Add an entry that the definition has been deprecated in NEWS and | |
441 | explain what do do instead. | |
442 | ||
443 | 5. In file TODO, there is a list of releases with reminders about what | |
444 | to do at each release. Add a reminder about the removal of the | |
445 | deprecated defintion at the appropriate release. | |
446 | ||
447 | - Please write log entries for functions written in C under the | |
448 | functions' C names, and write log entries for functions written in | |
449 | Scheme under the functions' Scheme names. Please don't do this: | |
450 | ||
451 | * procs.c, procs.h (procedure-documentation): Moved from eval.c. | |
452 | ||
453 | Entries like this make it harder to search the ChangeLogs, because you | |
454 | can never tell which name the entry will refer to. Instead, write this: | |
455 | ||
456 | * procs.c, procs.h (scm_procedure_documentation): Moved from eval.c. | |
457 | ||
458 | Changes like adding this line are special: | |
459 | ||
460 | SCM_PROC (s_map_in_order, "map-in-order", 2, 0, 1, scm_map); | |
461 | ||
462 | Since the change here is about the name itself --- we're adding a new | |
463 | alias for scm_map that guarantees the order in which we process list | |
464 | elements, but we're not changing scm_map at all --- it's appropriate | |
465 | to use the Scheme name in the log entry. | |
466 | ||
467 | - There's no need to keep a change log for a ChangeLog file. For any | |
468 | other kind of file (including documentation, since our documentation | |
469 | is indeed precisely engineered -- we surpass GNU standards here), add | |
470 | an appropriate ChangeLog entry when you change it. Simple! | |
471 | ||
472 | - Make sure you have papers from people before integrating their | |
473 | changes or contributions. This is very frustrating, but very | |
474 | important to do right. From maintain.texi, "Information for | |
475 | Maintainers of GNU Software": | |
476 | ||
477 | When incorporating changes from other people, make sure to follow the | |
478 | correct procedures. Doing this ensures that the FSF has the legal | |
479 | right to distribute and defend GNU software. | |
480 | ||
481 | For the sake of registering the copyright on later versions ofthe | |
482 | software you need to keep track of each person who makes significant | |
483 | changes. A change of ten lines or so, or a few such changes, in a | |
484 | large program is not significant. | |
485 | ||
486 | *Before* incorporating significant changes, make sure that the person | |
487 | has signed copyright papers, and that the Free Software Foundation has | |
488 | received them. | |
489 | ||
490 | If you receive contributions you want to use from someone, let me know | |
491 | and I'll take care of the administrivia. Put the contributions aside | |
492 | until we have the necessary papers. | |
493 | ||
494 | Once you accept a contribution, be sure to keep the files AUTHORS and | |
495 | THANKS uptodate. | |
496 | ||
497 | - When you make substantial changes to a file, add the current year to | |
498 | the list of years in the copyright notice at the top of the file. | |
499 | ||
500 | - When you get bug reports or patches from people, be sure to list | |
501 | them in THANKS. | |
502 | ||
503 | ||
504 | Naming conventions ================================================= | |
505 | ||
506 | We use certain naming conventions to structure the considerable number | |
507 | of global identifiers. All identifiers should be either all lower | |
508 | case or all upper case. Syllables are separated by underscores `_'. | |
509 | All non-static identifiers should start with scm_ or SCM_. Then might | |
510 | follow zero or more syllables giving the category of the identifier. | |
511 | The currently used category identifiers are | |
512 | ||
513 | t - type name | |
514 | ||
515 | c,C - something with a interface suited for C use. This is used | |
516 | to name functions that behave like Scheme primitives but | |
517 | have a more C friendly calling convention. | |
518 | ||
519 | i,I - internal to libguile. It is global, but not considered part | |
520 | of the libguile API. | |
521 | ||
522 | f - a SCM variable pointing to a Scheme function object. | |
523 | ||
524 | F - a bit mask for a flag. | |
525 | ||
526 | m - a macro transformer procedure | |
527 | ||
528 | n,N - a count of something | |
529 | ||
530 | s - a constant C string | |
531 | ||
532 | k - a SCM variable pointing to a keyword. | |
533 | ||
534 | sym - a SCM variable pointing to a symbol. | |
535 | ||
536 | var - a SCM variable pointing to a variable object. | |
537 | ||
538 | The follwing syllables also have a technical meaning: | |
539 | ||
540 | str - this denotes a zero terminated C string | |
541 | ||
542 | mem - a C string with an explicit count | |
543 | ||
544 | ||
545 | See also the file `devel/names.text'. | |
546 | ||
547 | ||
548 | Helpful hints ======================================================== | |
549 | ||
550 | - [From Mikael Djurfeldt] When working on the Guile internals, it is | |
551 | quite often practical to implement a scheme-level procedure which | |
552 | helps you examine the feature you're working on. | |
553 | ||
554 | Examples of such procedures are: pt-size, debug-hand and | |
555 | current-pstate. | |
556 | ||
557 | I've now put #ifdef GUILE_DEBUG around all such procedures, so that | |
558 | they are not compiled into the "normal" Guile library. Please do the | |
559 | same when you add new procedures/C functions for debugging purpose. | |
560 | ||
561 | You can define the GUILE_DEBUG flag by passing --enable-guile-debug to | |
562 | the configure script. | |
563 | ||
564 | - You'll see uses of the macro SCM_P scattered throughout the code; | |
565 | those are vestiges of a time when Guile was meant to compile on | |
566 | pre-ANSI compilers. Guile now requires ANSI C, so when you write new | |
567 | functions, feel free to use ANSI declarations, and please provide | |
568 | prototypes for everything. You don't need to use SCM_P in new code. | |
569 | ||
570 | ||
571 | Jim Blandy, and others | |
572 | ||
573 | ||
574 | Patches =========================================================== | |
575 | ||
576 | This one makes cvs-1.10 consider the file $CVSDOTIGNORE instead of | |
577 | .cvsignore when that environment variable is set. | |
578 | ||
579 | === patch start === | |
580 | diff -r -u cvs-1.10/src/cvs.h cvs-1.10.ignore-hack/src/cvs.h | |
581 | --- cvs-1.10/src/cvs.h Mon Jul 27 04:54:11 1998 | |
582 | +++ cvs-1.10.ignore-hack/src/cvs.h Sun Jan 23 12:58:09 2000 | |
583 | @@ -516,7 +516,7 @@ | |
584 | ||
585 | extern int ign_name PROTO ((char *name)); | |
586 | void ign_add PROTO((char *ign, int hold)); | |
587 | -void ign_add_file PROTO((char *file, int hold)); | |
588 | +int ign_add_file PROTO((char *file, int hold)); | |
589 | void ign_setup PROTO((void)); | |
590 | void ign_dir_add PROTO((char *name)); | |
591 | int ignore_directory PROTO((char *name)); | |
592 | diff -r -u cvs-1.10/src/ignore.c cvs-1.10.ignore-hack/src/ignore.c | |
593 | --- cvs-1.10/src/ignore.c Mon Sep 8 01:04:15 1997 | |
594 | +++ cvs-1.10.ignore-hack/src/ignore.c Sun Jan 23 12:57:50 2000 | |
595 | @@ -99,9 +99,9 @@ | |
596 | /* | |
597 | * Open a file and read lines, feeding each line to a line parser. Arrange | |
598 | * for keeping a temporary list of wildcards at the end, if the "hold" | |
599 | - * argument is set. | |
600 | + * argument is set. Return true when the file exists and has been handled. | |
601 | */ | |
602 | -void | |
603 | +int | |
604 | ign_add_file (file, hold) | |
605 | char *file; | |
606 | int hold; | |
607 | @@ -149,8 +149,8 @@ | |
608 | if (fp == NULL) | |
609 | { | |
610 | if (! existence_error (errno)) | |
611 | - error (0, errno, "cannot open %s", file); | |
612 | - return; | |
613 | + error (0, errno, "cannot open %s", file); | |
614 | + return 0; | |
615 | } | |
616 | while (getline (&line, &line_allocated, fp) >= 0) | |
617 | ign_add (line, hold); | |
618 | @@ -159,6 +159,7 @@ | |
619 | if (fclose (fp) < 0) | |
620 | error (0, errno, "cannot close %s", file); | |
621 | free (line); | |
622 | + return 1; | |
623 | } | |
624 | ||
625 | /* Parse a line of space-separated wildcards and add them to the list. */ | |
626 | @@ -375,6 +376,7 @@ | |
627 | struct stat sb; | |
628 | char *file; | |
629 | char *xdir; | |
630 | + char *cvsdotignore; | |
631 | ||
632 | /* Set SUBDIRS if we have subdirectory information in ENTRIES. */ | |
633 | if (entries == NULL) | |
634 | @@ -397,7 +399,10 @@ | |
635 | if (dirp == NULL) | |
636 | return; | |
637 | ||
638 | - ign_add_file (CVSDOTIGNORE, 1); | |
639 | + cvsdotignore = getenv("CVSDOTIGNORE"); | |
640 | + if (cvsdotignore == NULL || !ign_add_file (cvsdotignore, 1)) | |
641 | + ign_add_file (CVSDOTIGNORE, 1); | |
642 | + | |
643 | wrap_add_file (CVSDOTWRAPPER, 1); | |
644 | ||
645 | while ((dp = readdir (dirp)) != NULL) | |
646 | === patch end === | |
647 | ||
648 | This one is for pcl-cvs-2.9.2, so that `i' adds to the local | |
649 | .cvsignore file. | |
650 | ||
651 | === patch start === | |
652 | --- pcl-cvs.el~ Mon Nov 1 12:33:46 1999 | |
653 | +++ pcl-cvs.el Tue Jan 25 21:46:27 2000 | |
654 | @@ -1177,7 +1177,10 @@ | |
655 | "Append the file in FILEINFO to the .cvsignore file. | |
656 | Can only be used in the *cvs* buffer." | |
657 | (save-window-excursion | |
658 | - (set-buffer (find-file-noselect (expand-file-name ".cvsignore" dir))) | |
659 | + (set-buffer (find-file-noselect | |
660 | + (expand-file-name (or (getenv "CVSDOTIGNORE") | |
661 | + ".cvsignore") | |
662 | + dir))) | |
663 | (goto-char (point-max)) | |
664 | (unless (zerop (current-column)) (insert "\n")) | |
665 | (insert str "\n") | |
666 | === patch end === |