Re: Modularizing cons

[Brad Garcia]

On Fri, 31 Aug 2001, Steven Knight wrote:

> Why does adding the above logic bother you, when the logic for
> interpreting %LIBS and %LIBPATH and %PREFLIB and %SUFLIB are all "in
> there," too?

I think he is saying that this code actually belongs in a module too,
because different linkers have different knobs for controlling a build
in different ways (boy, that was repetitive!).

> So where does the line get drawn? 

I think "base" cons should have about the functionality of "make".
It should have no knowledge of tools at all.  Just the concept of
dependents, the MD5 checksums, etc.

> If both someone else's linker command
> use similar static/dynamic flags to mine, why should my builder have to
> duplicate that logic, but not the %LIBPATH logic?  Or does each builder
> always roll its own from scratch?

In any initial implementation, just duplicate it.
Later, you can figure out how to share code that is common between
modules.

> Agreed, with one exception: scanning for includes doesn't belong with
> the build tool, it belongs in a separate scanner object that's tied to
> the type of file being scanned.

Maybe, maybe not.
*Where* to look for included files may be tool-specific.

> Does all of this need to
> maintain backwards compatibility with the current Cons, or are people
> open to a *complete* rework for a hypothetical Cons 3.0, and losing
> backwards compatibility?

My opinion:

If you think it makes it easier to develop, then just ignore backwards
compatibility.

It's my feeling that once the work is done to modularize it, it will
actually be easy to tweak it afterwards to regain backwards compatibility.


Brad Garcia