Re: Modify files on before commit using loginfo?

[Paul Sander]

Have you considered something like this?

Create a special target in your makefile that performs all the auditing
of your process that you want.  Its prerequisites should be all of the
header files you're concerned about.  Put it under CVS control and commit it
with all of your sources, and apply the necessary verification using the
*info hooks.  List it in the prerequisite list of all of your first-order
derived objects (e.g. your .o files, but it need not actually be used in
the recipe).

Creating the audit file would be a simple matter of reading the user's
environment and running a few simple programs (e.g. cpp and grepping its
output for known strings).  The verification would be to compare the
user's audit file against a trusted template.  You could also add more
verification into the recipe that builds the audit file, and fail the
build if it doesn't match the trusted template.

This isn't a foolproof method to prevent the type of error that you
describe.  Touching the audit file avoids rebuilding it if its prerequisites
change.  It also causes unneeded compilations by introducing extraneous
prerequisites, but this can be improved by writing an audit file for every
shippable.

>--- Forwarded mail from address@hidden

>I'd like to provide an example of a case where something like this would be
>useful.  I want to prevent people from building a program that was compiled
>with 2 different versions of a C++ header file.  We already use the cvs
>ident command to look for problems like this, but it would be even better to
>prevent it in the first place.

>It would be great if we could declare a global variable with a name that
>contains the header file name and version number, e.g. for version 1.17 of
>foo.h,

>Extern int foo_h_1_17 = 0;

>Then in foo.c, we can define this global variable.  If someone has compiled
>some file with version 1.16 of foo.h instead of version 1.17, they will get
>a linker error.

>CVS has $Id$ and $Revision$ keywords, but they can't be used to build this
>variable name.  For one thing, the name can't have dots in it.  Running a
>script to modify the file either on checkout or commit would allow us to
>declare the variable.

>If anyone can suggest a scheme to automate a process like this, it would be
>greatly appreciated.

>>-- Forwarded mail from address@hidden

>Agreed.  Make the user make the change you want committed.  Supply a script
>to do it if necessary.  Then use the *info capability to verify that it
>was done.

>>--- Forwarded mail from address@hidden

>>Anders Carlberg <address@hidden> writes:

>>> Is it possible to modify the files before they are commited to the
>>> repository using loginfo or commitinfo?

>>At loginfo time it is already too late, the file has been committed to
>>the repository. At commitinfo time, you have access to the server side
>>copy of the files (or the original files if in :local: mode), so it may
>>be possible to whack in changes. Doing so is a very bad idea as it
>>introduces entropy that is not controlled by the user into the process
>>of trying to accurately record the state of files that 'worked' for the
>>user.

>>> How should I do this?

>>You should not do it. If you choose to do it, you may find yourself
>>in a world of hurt eventually.

>>> Is there a file stream I can read and write to?

>>Not really.

>>> Or should I do this via CVS commands (checking out and commit) (but then
>>> the files get a new version? Or?) ?

>>CVS is bright enough not to provide for this kind of lunacy/idiocy.

>>> Is there anyone that has done something like this?

>>Probably, folks have been abusing CVS in ways it was never intended to
>>be used for many years now. This does not make it a good idea.

>>--- End of forwarded message from address@hidden


>--- End of forwarded message from address@hidden