[Aldor-l] #line bugfix
Bill Page
bill.page at newsynthesis.org
Tue Dec 11 14:52:08 EST 2007
On 12/11/07, Gabriel Dos Reis wrote:
> On Tue, 11 Dec 2007, Bill Page wrote:
> | On 12/11/07, Laurentiu Dragan wrote:
> | >
> | > All patches should be guarded by EDIT_* to be easily
> | > enabled/disabled.
> | >
> | I don't understand this. I think decorating the source code
> | with conditionals would make the code more unreadable
>
> agreed.
>
> | and largely defeats | at least one of the reasons for using
> a source code control system.
>
> Why? I see complement, but defeat?
>
To "complement" something is to add some new functionality that is not
already present. If there is more than one way to accomplish the same
thing then very often one way "defeats" the other by making it
necessary to accommodate all the different ways of doing the same
thing. In so doing each way of doing the same thing is somehow less
powerful.
If the entire edit history of patches are to be "guarded" by EDIT_*
conditionals then the "state" of the source code must be defined not
only by the working file set but also by the particular set of dynamic
flags used during the build. This means that all comments or other
metadata added to the source code control system when committing a
patch must be conditional on whether or not the person who builds that
particular revision does nor does not choose to build it with a
specific flag. To me this clearly defeats the purpose of using a
source code (revision) control system to properly document changes to
the source.
> | Could you give an example of the expected usage?
>
> Well, you can compile the whole source with CPP defines on the
> command line.
>
These defines are dynamic. Where are they defined? How complicated can
we allow this to get? Should one expected to be able to re-create any
particular state of the source code by some combination of flags? If
not, where is it documented what options are available in each
revision? This creates in effect two levels of document about the
state of the source code.
> I'm not necessarily saying that is the way it should be done; but at
> least, I see the rationale. That may be quicker for binary search of
> a regression than going through svn up, svn diff, etc.
>
A good source code control system provides the tools to do an
automatic binary search for regressions. If one also has to deal with
a large number of optional flags that turn on or off various patches
this would prevent the use of such a facility to locate such
regressions.
Regards,
Bill Page.
More information about the Aldor-l
mailing list