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 the
> generation 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 create
speed_table.c (speed_table.pl) is about as unique as you can get... so
much 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, not
so 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.
Or would there then be trunk/tools/{toolname} for common ones and
trunk/tools/jtag/{interfacename}/{toolname} for ones specific to an
interface, etc.? In a project as complex as this one, namespace
pollution is sort of important to prevent. 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 contain
their source when they are more complex than one .c and one .h file, to
which you allude below?
I get what you're saying, and on the face of it, I agree, but, there do
seem to be contraindicating factors. If a scheme such as you suggest
can be arrived at in a way that everybody is satisfied with (or
ambivalent about), and somebody wants to put the work into it, I'm for it.
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). One of the reasons that my DTC compiler is in Perl is
that that meant I didn't have to mess with building it from C/lex/yacc
source. As it turns out, I could have just built it manually, as that's
how things ended up, but hopefully I've conveyed how that thinking went.
The other reason is that this was a quick one-off tool, and it was faster
to create it that way. And I haven't touched lex/yacc in years.
>
> As for whether rlink should be a folder under interface or just in
> interface, the general rule is if it is simply a single .c and .h, it
> lives in the interfaces folder. Anything more and it should be in a
> subfolder. That makes it clear which files belong to which interfaces.
> If the build system isn't setup to handle this today, I'm certain someone
> with more automake-fu can help make this happen.
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.
Are the general rules codified anywhere? 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}".
I'm hoping for the automake-fu. I certainly don't have it.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
