This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I'm still new at eCos, even though I've been toying around with it for over a year. What stymies me is, among other things, the persistent need to modify bits of the HAL, to fix problems that are sometimes due to minor differences between my hardware and the hardware it was originally designed for.
Is there a cleaner alternative than merely hacking the source file in the local copy of the repository? If I was experienced enough with eCos to take responsibility for making sure my change was appropriate for the rest of the world, then I'd just fix it in place, and learn how to submit the change to the community, but that's a separate issue. In the general case, I really just want to make the hack for my own hardware, and I'd like to do it in some way that doesn't get overwritten the next time I update eCos. What's the easiest way to deal with this?
What I did (when I was keeping up with ecos diligently) is check out copies of the ecos tree to a local directory, then check them in to our local CVS server as a 'vendor branch' with a tag specifying the checkout date. our local CVS would then keep track of our local changes and help with merging.
-- Hardware, n.: The parts of a computer system that can be kicked.
-- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |