Re: [MMXX-dev] New stuff

[Luca R. <lj...@us...>]

On 5/2/2000 7:15 AM, Frank V. Castellucci (fr...@co...) 
shared his wisdom:

>Couple of release points:
>
>I caught some flak over not using the automake, autoconf, and libtool
>release standards. Your call.

Yes, well the main issues are that autoconf is not really that "portable" 
(no Mac/Windows) which complicates things in terms of internal 
dependencies, and also that since MMXX is currently intended to be 
included in source form "en toto" in user projects (rather than say, 
place itself somewhere under /usr/include and the likes and be a project 
dependency, since again Mac/Windows have no /usr/include) then open 
source user projects would end up having to use autoconf on un*x even if 
they don't wish to, and if they already do, they'd have to merge their 
configure.in's and share their config.h's with MMXX and/or recurse to 
them and avoid naming conflicts etc. etc.

The other thing is that autoconf is very good at isolating unix system 
dependencies and has a lot of rules for those, but MMXX has very few of 
those (currently just the standard library stuff and the dlopen() 
interface.) Its major dependencies are with the compiler's C++ support, 
which are mostly idiosyncratic in nature, meaning that that they're hard 
to account for without witnessing them on an individual basis, at which 
point we know the compiler/version and can just #if it away.

This might become a good idea later, i.e. if/when the MMXX support code 
itself becomes a MMXX-enabled library, but this is definitely not going 
to happen before the ABI settles down to its final form and/or its object 
size becomes significant. At the moment isolating the MMXX support code 
in a library would actually *increase* overall object size (because we'd 
be adding an extra module), and since there's no MMXX libraries out there 
yet, for now I think it'd be mostly a headache.

>
>I hate doing it myself, but I beg you: At least provide serious
>documentation in the headers!!! 
>

Hehe yes, you're absolutely right. I've been adding a bit with this 
release, unfortunately one problem I've been running into is that as soon 
as I comment something, I revise it soon after to make the comment 
obsolete, worse yet I tend to forget about having written it which ends 
up deceiving the reader! As things stabilize further I will be adding 
more.

Documentation is really a major issue at this stage, since 90% or so of 
the 1.0 features are there, now is about the right time to start focusing 
on it. I've extended the "overview" file, I promise I will add to the 
"advanced internals" file to cover some of the many missing aspects, but 
other than that I'd really need to get some help here. BTW if we're to 
revise the terminology, this would be a great time to do that also. Once 
those are done, and we get some tutorials and decent test suites, we 
could move to Alpha status and start "marketing" to users.

Indeed, I've so far refrained from posting in high-visibility places 
(such as say, comp.lang.c++, mailing lists, etc.) because I was afraid to 
turn off people who'd come in only to realize there was hardly enough for 
them to learn to use it without putting in a huge reverse engineering 
effort.

BTW, if you ask questions here on the list I'd be happy to answer them. 
That way there's a record of at least some of the confusing aspects, and 
the bits and pieces that come through here might become part of a FAQ 
later.

Ciao!
Luca