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.
>>
>> 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.
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.
>
>> 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.
>> 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.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
