[Biot Olivier <Olivier.Biot@xxxxxxxxxxx>]

Or should we generate register.c in 2 steps as proposed in the Makefile,
where the 1st step is only invoked if a source file has been edited, and the
2nd step consolidates all protocol-specific register files to one single
"register.c"? In order to avoid flooding of the main Ethereal source
directory, I would propose to create a "register" directory in which we
store the individual register-PROTO.[ch] files.

I think it makes sense to optimize the generation of register.c as there are
now many protocols in Ethereal, and every protocol addition requires more
computational time at compilation.

Right now, I just commented out the generation of register.c in the Makefile
as I'm only changing the dissection code for one protocol. If I leave the
Makefile untouched, then I have to wait for 5-10 minutes in order to compile
Ethereal once (I'm working 100% in cygwin on Win2K). If I leave out the
register.c generation, this time is reduced to ~1 minute which is acceptable
to me.

Regards,

Olivier

> -----Original Message-----
> From: Jason House [mailto:jhouse@xxxxxxxxx]
> Sent: dinsdag 11 februari 2003 1:04
> To: Biot Olivier
> Cc: Ethereal-Dev (E-mail)
> Subject: Re: [Ethereal-dev] Prevent generation of register.c
> 
> 
> Maybe the proper solution would not to have a lockfile, but 
> instead have some
> better means of detecting wether register.c needs to be 
> made...  As it is now,
> register.c needs to be remade every time a protocol dissector 
> needs to get
> recompiled.  I assume that you want a lock file because you 
> are modifying
> dissector code, and every time you compile your changes, you 
> have to wait for
> register.c?
> 
> I'm trying to think of a good way to come up with a proper 
> solution... I think
> it boils down to the fact that there can be mutliple 
> proto_register_<protocol
> name>() functions in a single packet-<protocol name>.c file...
> 
> Here's some quick checks that I did (on a mildly out of date version):
> 
> $ grep -c -E "^proto_register" *.c | grep -v ":0" | grep -v 
> ":1" | wc -l
>       8
> 
> $ grep -c proto_register_protocol *.c | grep -v ":0" | grep 
> -v ":1" | wc -l
>      23
> 
> $ ls packet-*.c | wc -l
>     305
> 
> It looks to me like there's 8 protocols that cause trouble by 
> requiring
> multiple calls to proto_register (ie. vines)...  But there 
> are other protocols
> such as apple talk that call proto_register_protocol up to 7 times
> 
> $ grep -c proto_register_protocol packet-atalk.c
> 7
> 
> Can we learn something from apple talk?  How bad would it be 
> to require that
> each packet-*.c file contains only one call to 
> proto_register_<protocol
> name>() ?  Can this be such a bad trade off for the few rare 
> cases?  If the
> requirement went one step further rquiring the 
> proto_register_<protocol name>
> to use the same name as packet-<protocol name>.c, then 
> generating register.c
> would not need to scan every file (probably a great speed 
> boost there) and
> would only need to get regenerated when a completely new file 
> is created.
> 
> Again, that's probably what most of the dissectors do 
> already...  it's just
> the few exceptions that cause the problem...  When I did 
> development in the
> past register.c bothered me a lot... In the past, I've edited 
> the makefile to
> stop register.c from being made :)
> 
> This would basically make register.c require compilation only 
> when things such
> as the makefile itself was modified (ie. to add a new 
> dissector to the list of
> dissectors to compile)
> 
> 
> 
> Biot Olivier wrote:
> 
> > Hi all,
> >
> > How about a lock file in order to prevent the generation of 
> the register.c
> > file? Amending the makefiles should not be too difficult 
> (check for the
> > existence of a "lock" file).
> >
> > Regards,
> >
> > Olivier
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> 
>