On Dec 3, 2008, at 12:38 PM, Øyvind Harboe wrote:
On Wed, Dec 3, 2008 at 9:28 PM, Rick Altherr <[EMAIL PROTECTED]> wrote:On Dec 3, 2008, at 12:17 PM, Øyvind Harboe wrote:Either it should be part of the main OpenOCD source base or it should be separate project. If it is just a flash, interface, and target driver,thenit should just be part of the mainline source base. If it is more thanthat, it isn't really part of OpenOCD.It *is* part of the main openocd source base. This is just a technicalityw.r.t.avoiding excessive download sizes for those that don't need those bits.It looks like it contains the build environment for the zy1000 firmwarewhich _uses_ OpenOCD but isn't part of OpenOCD.The whole point of a version control system is to be able to go back and *build* some older version.
Correct, and anyone can go build OpenOCD 1.0 once it is tagged without the contents of the zy1000 directory.
The zy1000 directory contains the prerequisites to build the binary.
To build the zy1000 firmware, not OpenOCD.
embedded is different from building for developer operating systems.
Yup, but zy1000 is not OpenOCD. It is a separate project.
It is also an embedded version of openocd, so it is built very differentlyfrom openocd hosted on a developer OS.Exactly, it isn't part of OpenOCD, but rather a user of OpenOCD. Justbecause OpenOCD does a release doesn't mean that the zy1000 buildenvironment needs to be changed. For example, OpenOCD might release 1.0.1that contains a big bug that makes the zy1000 non-functional. It iscompletely reasonable in that case for the zy1000 build scripts to useOpenOCD 1.0 instead with no real impact.Note that the zy1000 directory also contains *code* for openocd, not only the build scripts. All of that code, combined, is GPL and there is no way to mix and match versions of tools and other code that goes into the final mix.
If the zy1000 build scripts patch OpenOCD, that's fine, but it doesn't mean that the zy1000 scripts must be tied to OpenOCD releases or that the zy1000 firmware is part of the OpenOCD project. If anything this is more evidence that the zy1000 is a separate project that extends OpenOCD and should be treated as a separate project.
It is not necessary to complicate the life of most developers out there with the nasty bits that goes into building an embedded product and a separatefolder solves this.
Exactly, we shouldn't complicate the state of affairs for the majority of developers. So, the trunk should contain the OpenOCD release. That does not include the patches to build support for the zy1000. The build system and patches for the zy1000 should be maintained separately.
The ZY1000 is a commercial product built on top of OpenOCD. The scripts and files necessary to build the ZY1000 firmware are not part of OpenOCD. They are part of the ZY1000 software. OpenOCD is simply a component of theZY1000 software.What are you trying to say here?
That OpenOCD and the ZY1000 are separate projects. OpenOCD is a piece of software designed to run on a variety of OSes and utilize a variety of JTAG interfaces. The ZY1000 is a device containing both hardware and software. The software for the ZY1000 is a specific OS and a modified version of an OpenOCD release.
OpenOCD is GPL and ZY1000 uses OpenOCD, so the resulting code is GPL.
OpenOCD is an application running on the OS packaged as part of the ZY1000. Not all of the ZY1000 is required to be GPL nor does licensing have anything to do with whether the two projects should be treated as one.
Where does "commerical" enter into it? GPL does not mean non- commerical. In fact commercial and non-commerical is equal from GPL's point of view.
That OpenOCD is free and the ZY1000 is not is simply another distinction that they are 2 separate projects with different goals and deliverables.
What's the problem you're trying to address?
Tying the two into a common directory structure means that when OpenOCD releases version 1.0, the ZY1000 firmware will also become version 1.0. While the two might have release coincide frequently, this links all ZY1000 firmware versions to an corresponding OpenOCD version. If a bug in a non-OpenOCD portion of the ZY1000 firmware was to be fixed but no changes were made in the OpenOCD portion, there is no reason to make a new OpenOCD version, yet the layout of the repository would cause a new version of OpenOCD to be tagged.
What are you suggesting?
Treat OpenOCD and ZY1000 as separate projects. Lay out the directory structure like:
openocd/ trunk/ tags/ branches/ zy1000/ trunk/ tags/ branches/That way the zy1000 firmware can be versioned independently of OpenOCD. The zy1000 scripts can check out a specific version of OpenOCD so the version locked changes can be handled gracefully when building the zy1000 firmware. This way, OpenOCD can release version 1.0.1 which breaks the zy1000 patches, but the zy1000 firmware can still build using the OpenOCD 1.0 release.
Tying a components versioning to that of a package it is delivered in only leads to headaches when making releases. I speak from years of experience on this exact issue.
-- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer
-- 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
