Hi Seb,
On 2010/11/24 10:27, Sebastien Lelong wrote:
Not related to this issue, but since it seems MPLAB inconsistencies are
growing fast, do you think storing device files in SVN would help ? When
deploying a new version of device files, you would see the differences
using "svn diff" (well I'm sure you know the differences anyway), and
you would only commit safe device files, lately used by dev2jal. This is
also to consider if device file format changes and we want to keep the
original device file format, avoiding migrating dev2jal.
Maybe good to tell (partly repeat) my way of working.
With a new version of MPLAB I usually simply generate a new set of
device files and then compare the new files with the current (latest
committed) files.
I do this with a script (to skip the header which is always different
because of date and MPLAB version), and when there are differences the
script calls KDIFF3 to show the files on the screen (I use a PC with 2
screens so I see both files in full width).
When in doubt about the cause of a difference I do something similar
with the .dev files in MPLAB (compare new and previous version).
Usually this works fine, because generally there are not that many
differences. But with mplab 8.60 there were so many differences that
this did not really work. So I had to adapt the dev2jal script to
smoothen out the differences before the number and kind of differences
became comprehensible. Then I noticed the 'missing' pins, but since all
samples compiled OK and some of my tests showed also no problems, I
decided to commit because I thought the missing pins were of far less
importance than the corrections/fixes of other parts. In a previous
conversation I announced that the conversion to 8.60 would be probably
be a step-by-step approach, correcting initial errors in following
step(s).
Now about your suggestion: when I understand you correctly you want to
keep two or more 'generations' of device files (something like we had in
the beginning of Jallib with 'validated' and 'unvalidated') and replace
validated files selectively (one-by-one) when these proved to be OK. I'm
not so sure this is desirable, mostly because it is much more work and
the benefit is marginal (I think). You can always go back to a previous
revision. After all the current contents of Jallib is a development
situation. With a new release we do some more checks and tests and
freeze it. Users may prefer such a release over a last-minute
development, which is up to them.
Maybe this is not what you mean, in that case could you be more explicit?
Regards, Rob.
--
R. Hamerling, Netherlands --- http://www.robh.nl
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en.
