Prev: Generate Assembly File Via Borland 3.1
Next: linker script and compilers.....
From: Hans-Bernhard Bröker on 2 May 2010 16:15
Gary Lynch wrote:

> Let's say my executable comes from 2 source files (in C),
> holding 3 & 4 functions; respectively:

[...]

The root of your problem would seem to be this very way you organized
your functions into files.

> This is the way it looked when I released revision R1.6. My
> manager wanted me to follow that up with inclusion of 2 new
> features:
>
> H New hardware: The new platform has more I/O ports,
> more complex signal processing,
>
> I Input Sampling: Due to a misunderstood requirement, I
> had been sampling 2 input signals at the same
> frequency. When one of them needed more noise
> filtering while the other needed quicker response
> time, I had to split them into separate processing
> pipes, with new names.

The fact that these two changes each affected several functions spread
over the same two source files indicates that the module structure was
in severe need of re-factoring before this all began.

At the very least, it would have been highly advisable to disentangle
the changes needed for these two features. Otherwise you'll have a
serious problem on your hands as soon as somebody wants 'I' on the
pre-'H' hardware. I.e. there should have been separate '.H' and '.I'
versions of each file, and the '.HI' version should have been arrived at
by merging those two.

> At this point, what I really need is a utility that would
> allow me to implement the top-level command:
>
> R1.7.HI = R1.7 + (R1.6.HI - R1.6)

I.e. you need to merge changes from two different branches (1.7 and
1.6.HI) off the same common ancestor (1.6) to arrive at a new version
--- what I tend to call a three-way merge.

Any revision control system worth its salt would have a command for
that, or at least allow you to just use stand-alone tools for that
purpose --- on a file-by-file level, that is. Moving stuff from one
file to the other tends to prevent usage of any such tools, so your best
bet would be either "Don't do that, then!", or at least, if you have to,
do it _before_ you make substantial changes to the functionality of the
code.

You'll likely be down to generating diffs and editing those into the
individual files somewhat manually, or at least interactively.

> Furthermore, writing this down makes me realize my problem is in the
> tools, for whom the smallest unit of analysis is the file; whereas in
> my source deck, the "atoms" are really functions.

There's no particularly strong reason for those types of atoms to be so
different. "One file per function" is not always a good idea, but for
your way of coding, it might be better than the way you appear to spread
aspects of functionality across functions, and functions across files,
right now.
From: Ira Baxter on 6 May 2010 11:14

"Gary Lynch" <bookworm(a)execpc.com> wrote in message
news:20100502-175826.354.0(a)Gary-Lynch.news-radius.core.com...
>I am looking for a tool to facilitate maintenance of a
> firmware-based product, but I don't know whether it exists,
> nor do I have a name for it.

[snip]

> Furthermore, writing this down makes me realize my problem
> is in the tools, for whom the smallest unit of analysis is
> the file; whereas in my source deck, the "atoms" are really
> functions.
>
> So I'll stop the example here and ask:
> - Does such a tool exist?
> - Is there a generic name for it?
> - Where do I learn more about this topic?

I agree. Configuration management needs to be in terms of the smallest unit
that might need to be configured.

If you carry this out the the extreme, you need to configure arguably
individual tokens in the langauge
(and if you go nuts, individual characters). That's difficult to do as a
practical matter, so somewhere you
have draw the line about how much stuff is in a single group and is managed
by the configuration management tool.
All other configuration management below that level has to be handle by
(preprocessor) conditionals :-{

Present tools do this by implicitly assuming that "file" is the right unit
to be managed, and that's much of your complaint.
The real problem here is that the software engineer decides arbitrarily what
goes into each file,
leaving the configuration management tool not a lot of choice.

Your suggestion of managing "functions" (I would have said, "declarations")
is IMHO
a better one but not one we're likely to get the existing configuration
management tools to change. Part of
the problem here is that configuration tools don't have any sense of
"boundaries" in terms of language constructs.

One step in that direction would be "diff" tools that do understand language
entities (identifiers, expressions, statements,
blocks, functions) and the actions applied to them (insert, replace, delete,
move, copy, rename).
See http://www.semanticdesigns.com/Products/SmartDifferencer/index.html


--
Ira Baxter, CTO
www.semanticdesigns.com



First  |  Prev  | 
Pages: 1 2
Prev: Generate Assembly File Via Borland 3.1
Next: linker script and compilers.....