On 8/24/07, Richard van der Hoff <richardv@xxxxxxxxxxxxx> wrote:
> Richard van der Hoff wrote:
> > Ok. I still don't have an oid_to_subid_buf, though :(
> Right. For now, I have cut and pasted the old oid_to_subid_buf into
> oid_resolv.c. This at least has made things build again.
there is oid_encoded2subid() in oids.c which does the same, I'll
change the users of that to use the old one.
> LEGO, can I suggest that in future you don't even commit the templates
> for autogenerated files, such that we don't get into this situation.
I needed to have a reference, I got that code working and before a
further iteration I wanted to be able to keep track of what I did. I
know the right way would have being to fork a new branch keep working
on that and later on merge it to the trunk. But keeping the generated
and the oids.[ch] files out of the way looked a usable shortcut. I
could have disabled the copy_files target and the problem would not
had happened... But to be sincere I do not think it's was such a
harmful thing, it's not like I wrecked the codebase and made it
unusable, it was just a forced rollout.
> Incidentally, is the right process for generating the asn dissectors to
> run "make" from the asn/* directories and then copy the generated files
> across? It seems kludgy, but I couldn't see a better way.
(cd asn/snmp && make copy_files)
> What is the reasoning behind checking in the generated asn dissectors?
> Is this for people without python on their boxes?
No it's because the asn2wrs compiler is not considered to be stable
enough yet to make the generated files targets in the makefiles. I
think Thomas will take the steps to make those files targets whenever
he feels it's time.
Luis
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
