Re: [Openocd-development] Patch submission for new interface support

Thu, 18 Dec 2008 08:22:01 -0800 


On Dec 18, 2008, at 8:16 AM, [email protected] wrote:


On Wed, Dec 17, 2008 at 10:40:58AM -0800, Rick Altherr wrote:
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.


Ok, but is this something that would be good to do for the entire
project for the future, or is it something that needs to be set up
before I can get my patch in?  It seems to me that such a change would
require everybody with such tools in their part to move them there.
Once the new scheme is figured out, each part would likely be fairly
easy.  Any one person trying to do them all would be in for headaches,
though.

I get your point.  But if I were to just go and create
tools/rlink_dtcas and tools/rlink_speed_table directories and nobody
followed on, I'd look a bit silly. It works the way it is, and at such a time as a scheme such as you propose is enacted, it shouldn't be a huge 
deal to make the necessary modifications to the parts affected by my
patch.
Being the organizational neat freak that I am, I would prefer if you went ahead and put the rlink tools in trunk/tools. I'll locate any others that are already in the source base and move them. Having _something_ in trunk/tools will mean that future tools would have a defined location and we would request that the patch author place them there.
Am in compliance with that general rule? I happened to arrive at the 
scheme 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.
I've moved it in there, but the .o file still gets built in the src/ jtag 
directory.  I assume that is consistent with what you're saying.
Otherwise, automake seems to be working against us.
That works for now. There are ways to make automake build the rlink directory separately, but that isn't so much of a concern as separating the source files. 


I don't know what that gains us, but it is done.  Leaving rlink.c out
there with the others seemed to make more sense to me. Especially since 
I now know that the .o file ends up there anyway.  But I have moved it
into the directory pursuant to your suggestion. Moving it back wouldn't 
be a huge deal.  Just a "svn mv" and an edit to Makefile.am.
It means that all of the rlink files are in one place so it is easier to determine what all is used by rlink and only rlink. 




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.
It would be helpful, particularly to new people, to have a document that 
enumerates how things are laid out and how people are expected to do
things.  Particularly for situations such as mine where there are no
existing examples, yet, from which to crib.



Agreed.  This should be done before our 1.0 release.


I had to google to find the
coding standard, and that was nothing current, just a thread saying
that
one had once been mentioned in a README (or something similar), but no 
longer 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
location
in 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.


That's how I knew to look up the earlier part of the thread.


I've copied it here for your reference:


Yup.  That's what I was referring to.

This point was really about my experience with trying to find out how
the community wanted ceratin things done.  It was merely a specific
example.


--
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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to