CVS update: samba/source/ubiqx

[Andrew Tridgell]

> Nope.  Unless you want to copy the ubiqx code and maintain it as a
> separate stream (which we can certainly do, it's just a maintenance
> nightmare), then I don't want to need this kind of thing.  I'd really 
> like to make sure that the modules can stand alone.  If I do this for 
> Samba, how many other packages that use the ubiqx stuff will want their 
> own #ifdef???

I don't know, but with my Samba hat on I have to say "that isn't my
problem" :)

I know that you don't want this to be necessary, but it really is
necessary and we have to live with it.

> I think you're thinking monolithically.

yep! and proud of it.

It is much easier to maintain a package like Samba when it uses a
monolithic includes file that handles all the weird cases. 

> The ubiqx stuff needs to be portable to these platforms anyway -- on it's 
> own.

sure, it needs to be, but is it? You're forgetting that we (ie. the
Samba team) have no control over the original ubiqx distribution. You
have that control but "we" don't. So to fix things we either have to
go via you and justify each #include for each platform or we need to
change it in the Samba tree. 

The same happens with every library we include in Samba. The same also
happens with every portable freeware package out there. Source
libraries that get included get modified to fit in with the package
specific build system. That's how it works!

We can use lukes idea of a ubi_includes.h file if you like, with an
#ifdef SAMBA in there. What we can't do is have code in our tree which
we aren't allowed to modify, and that is what you are essentially
saying.

> Again, I believe that you are thinking in terms of the whole, and not the 
> pieces.

that's right, I am. The millions of people who download and compile
Samba compile the whole, not the pieces. 

> It's worth while knowing what each module needs, and from where 
> it should get what it needs.  Really.

nope, it is worth using a single includes file so you don't need to
know! 

there are 271 source files in Samba today. You want me to know what
includes each one needs? I have better uses for my limited memory :)

> > Reusable code (in the sense of taking a whole file and putting it in
> > another package with no changes whatsoever) doesn't exist.
> 
> Oooohh.  Sure it does, or at least we can come quite close.  Perhaps it is
> asymptotic as you suggest.  That doesn't make it futile to attempt.

we did attempt it. We ended up releasing 1.9.18p5 which wouldn't
compile on SunOS4, which is one of our biggest platforms.

> The code in the ubiqx/source directory consists of "very simple code that
> calls very few functions".  In fact, there shouldn't be any calls to
> outside functions.  I designed the modules to work without having to
> reference anything outside.  The one clear exception would be NULL (which
> isn't a function). 

yeah, but even simple code needs includes.

One example is pointer manipulation. ubiqx style code often needs to
take the difference between two pointers. Many people just cast the
result to an int, but this ain't portable (and breaks badly on some
systems). The right way is to use ptrdiff_t. But where do you get
ptrdiff_t from? That varies enormously on different platforms.

BTW, how do you handle this now in ubiqx? Maybe you don't have any
pointer differencing?

> So, the ubiqx modules are supposed to work on just about any platform. 

supposed to, but as we found out they don't. So you could fix that
case. Then the next case crops up. 

> I don't see why we should need to create a separate strain and additional 
> maintenance track just to handle this one issue.

If it was just this issue then fine. The problem is that it won't be
just this issue. What about when you want to open a file in ubiqx?
Where do you get O_EXCL from? What about pointer differencing? Memory
allocation? string functions? memset vs bzero ? bcopy vs memcpy? 

are you never going to use any of the above in ubiqx? If you do, then
where do you get the right includes from?

uniqx is really simple now and may not need many of the above, but it
is growing. 

Cheers, Andrew