Mercurial > hg > index.cgi
view 00README.txt @ 338:5d401d1eb3e9
Allow disabling debugging messages.
Add test for LWASM_NODEBUG symbol to disable compiling the actual debug
message handling code.
Also, prevent building the debug message arguments if the debug level is not
going to display the message anyway. This comes at the possible expense of
larger code due to wrapping the debug_mesage() function in a macro that
tests the debug level directly. This should prevent calling expensive things
like building a dump of an expression when it is not required.
author | William Astle <lost@l-w.ca> |
---|---|
date | Tue, 05 Aug 2014 22:04:23 -0600 |
parents | 69adaab94ffd |
children | 48b1cc3991d8 |
line wrap: on
line source
This is LWTOOLS, a cross development system targetting the 6809 CPU. It consists of an assembler, lwasm, a linker, lwlink, and an archiver, lwar which should compile on any reasonably modern POSIX environment. If you have problems building, make sure you are using GNU make. Other make programs may work but GNU make is known to work. To see if a quick build will work, just type "make". If it works, you're ready to go ahead with "make install". This will install in /usr/local/bin. If you feel adventurous, you can also run the test suite by running "make test". However, be warned that it is likely not going to work unless you are running on a fairly standard unix system with perl in /usr/bin/perl. See docs/ for additional information. CONTRIBUTING ============ If you wish to contribute patches or code to lwtools, please keep the following in mind. Style ----- The code formatting style must match the rest of the lwtools code. Code submitted in the "1TBS" will be rejected out of hand. Attempts to convince me to change my mind on this point will be routed to /dev/null at best and likely met with extreme rudeness. C code should be formatted as follows: * All indentation uses a single TAB character for each step. That is a HARD tab, not a series of spaces. TABs are assumed to be 4 characters though that will largely impact only lining up comments and tabular code. If the actual formatting of the code is critical, spaces may be used for that formatting but the actual initial indentation of the lines MUST use TAB characters. * The opening brace for a block appears on the line below the control structure that introduces it. It appears lined up with the preceding line and nothing else appears on the same line. * Closing braces appear on a line by themselves ordinarily. The exception is the "while" keyword in a "do-while" statement appears on the same line as the closing brace for the block. * Case labels are lined up with the enclosing block (one level back from the code of the block). The same guideline applies for ordinarily labels. * No spaces surround parentheses, brackets, or the dot operator. No space precedes a comma but a space should follow it. Other operators should usually be surrounded by spaces. A space should separate a keyword from any surrounding except for sizeof() which should be written like a function call. There is no space between a function name and the start of its parameter list. In general, study the existing source formatting and copy the style. This is what you should do anyway and the above should not be required. For code accepted to the contrib/ hierarchy, application of the above coding style may be less strict. Submitting ---------- When submitting code to lwtools, it should be submitted as a patch file (hg diff or diff -u). DO NOT submit entire source files. Remember, others may be working on changes, too, and your complete source files are difficult to merge with such situations. By submitting complete source files, you are making far more work for the maintainer and it is generally considered rude. Always specify what version of the source you based your patch on. If possible, work off the default branch in the mercurial repository. At the very least, make sure you are working with the most recent release. It is also worth checking with the maintainer before submitting a patch. There may be some reason why your pet feature is not present in the official release. Finally, be prepared to receive a list of deficiencies or requests for improvements or clarification of why or how you did something.