Shantonu Sen <[EMAIL PROTECTED]> writes:
> Ok, so the dependency graph appears to be (forgive my ASCII art):
> 
>        anno
>    ____|  |____
>    |          |
>    |         smtp
>    |          |
>    libmh_____ |
>      |
>    generic
> 
> I picked "anno" simply as an example. smtp needs libmh for
> ruserpass, and libmh need generic for some mmdl* stuff. This
> was not a problem before, since the generic mts code was in zotnet
> and the dependencies could be resolved at link time via the proper
> ordering. With generic and smtp both in the same archive, this
> can't be done.
> 
> When I merged the generic and smtp into a libmts, I mistakenly
> thought that libmh wouldn't have dependencies on other code, which
> I would say is not an unreasonable assumption. Two solutions present
> themselves:
> 
> 1) split the generic code back into another archive and handle the
>    problem by changing the order in the Makefiles.
> 
> 2) move the generic code into sbr/ and add it to libmh
> 
> I personally would prefer 2) as it makes libmh more self-contained
> and we don't need to worry about dependency graphs as much. I have
> some concerns that the code may not play nicely as a part of libmh because
> it appears to try to override some functions, but we'll know for sure
> whether it's a real problem soon.
> 
> 1) would probably be the safest option, since it was known to work with
> the libzot stuff. But I don't particularly care for the approach. And if
> anyone chooses to use some of this code, they will need to spend time
> figuring out dependencies that we should really make transparent.
> 
> Thoughts?

I'd need to look at the code in more detail than unfortunately I have time
for right now in order to make a completely informed decision, but your
reasoning seems sound.  My only preference in all this is for nmh to
compilable again sooner rather than later.

-----------------------------------------------------------------------
Dan Harkless                   | To prevent SPAM contamination, please 
[EMAIL PROTECTED]      | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW.  Thank you.     

Reply via email to