On Dec 17, 2008, at 10:03 AM, [email protected] wrote:
On Wed, Dec 17, 2008 at 08:57:14AM -0800, Rick Altherr wrote:On Dec 17, 2008, at 3:01 AM, Øyvind Harboe wrote:We've got lots of other examples, e.g. the at91fr40162 flash driver contains a .elf file that is compiled with an arm-elf toolchain using eCos source. We're *NOT* going to make that part normal OpenOCD builds! :-)If these are truly infrequent operations, then perhaps moving thegeneration tool to trunk/tools/{toolname} is probably a better location.The generated files would still live in the interface folder, but the tool doesn't need to be there and isn't really part of the source.Except that it can be. In this case in particular, the DTC assembler(dtcas.pl) is unique to this particular interface, and the tool to createspeed_table.c (speed_table.pl) is about as unique as you can get... somuch so that it is a dependency of the target, since a change in it has that much influence on the target. I get it, though. In theory, the DTC compiler could be used by multiple interfaces. Still, the latter one, notso much. It would have to be genericized a lot and use one or more templates as part of its input, in order to be something general.
Things in a trunk/tools directory wouldn't be required to be generic to every target, interface, etc. The idea is to have a location where tools that are useful for maintainers and developers can be located away from the source used by everyone else. If speed_table.c and the DTC headers do not change frequently, then it is completely reasonable to check in both the source files and the generated files into jtag/ rlink directory but still put the tools in trunk/tools so that should the source files need to be changed, the generated files can be generated without tracking down extra software.
Or would there then be trunk/tools/{toolname} for common ones and
trunk/tools/jtag/{interfacename}/{toolname} for ones specific to an
interface, etc.?
There could be, but I don't see a reason to. If the tools are reasonably named, there would be no overlap and only developers of OpenOCD would be expected to use these tools.
Would there have to be a separate bin directory for tools to prevent naming conflicts between executables with no filename suffix and the directories that containtheir source when they are more complex than one .c and one .h file, towhich you allude below?
The tools would not be installed during a 'make install'. They shouldn't even be built during a 'make'. The idea is to have the tools available in the source tree for developer use, but not to use them for typical user compilations and installations. If a developers needs a tool, a simple 'make' in the tool directory should build the tool.
In such a scheme, I'd hope there is a way to _build_ such tools when they're going to be needed by a given configuration (only the rlink interface would need to build a DTC compiler, for example, though,persuant to above thinking, more than one conceivably could, but, still,most wouldn't).
Right, the intent is to avoid building the tools at all unless a developer needs the tool and builds it manually. A typical user compilation would never touch anything in the tools folder.
Am in compliance with that general rule? I happened to arrive at thescheme I used without knowing about the rule, but it is what made sense.
It appears that there are a number of files associated with the rlink interface (speed_table.c, rlink.c, rlink.h, dtc_something.h) so putting them in a separate directory is appropriate. Right now, you have many of the files in a separate directory but have rlink.c in the top-level jtag folder. Moving all the source files into the rlink folder is probably the right move.
Are the general rules codified anywhere?
This particular "rule" isn't really an OpenOCD rule. It is a convention used by many many projects that I personally prefer to follow. It keeps the directory structure clean and easy to navigate. It also helps indicate which files apply to what interface. If the rest of the OpenOCD developers have no objections, it could be formalized.
I had to google to find thecoding standard, and that was nothing current, just a thread saying thatone had once been mentioned in a README (or something similar), but nolonger is, but would be in the future (but isn't, almost a year later). It would be a lot easier for somebody (particularly a new somebody, such as myself) to comply with such rules if we know what they are. It could prevent several conversations such as this one, or at least reduce them to "read the document named {whatever it is called} at {URL or locationin source tree or either}".
There was something about this on the list a few days ago. The old README included a brief note on coding style and naming conventions. I've copied it here for your reference:
5. Coding StyleThe following rules try to describe formatting and naming conventions that
should be followed to make the whole OpenOCD code look more consistent.The ultimate goal of coding style should be readability, and these rules may
be ignored for a particular (small) piece of code if that makes it more readable. Formatting rules: - remove any trailing white space - use TAB characters for indentation, not spaces - displayed TAB width is 4 characters - make sure NOT to use DOS '\r\n' line feeds - do not add more than 2 empty lines to source files - do not add trailing empty lines to source files - do not use C++ style comments (//) - lines may be reasonably wide - there's no anachronistic 80 characters limit Naming rules: - identifiers use lower-case letters only- identifiers consisting of multiple words use underline characters between
consecutive words - macros use upper-case letters only - structure names shall be appended with '_s' - typedefs shall be appended with '_t' Function calls:- function calls have no space between the functions name and the parameter
list: my_func(param1, param2, ...)
I'm hoping for the automake-fu. I certainly don't have it.
-- Rick Altherr [email protected]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
