"Garrett D'Amore" <Garrett.Damore at Sun.COM> wrote:
> > Star is an integrated source for all three CLI interfaces and more.
> > Star could replace the current binaries in future, but then I/we need to
> > implement support for private extensions in the current OpenSolaris code.
> >
>
> As far as I'm concerned, if we can make star do all this, integrate well
> into Solaris (and probably ON), then I'm all for going down this route.
>
> As a question, what is your take on dealing with possible code forks
> here? I.e. if Solaris needs/wants some change to the source code at
> some point in the future, how happy will you be to accommodate such a
> change, even if it is not necessarily best for the "portable" version of
> the code? (I don't have anything specifically in mind, other than
> perhaps the automatic configuration bits.)
This is a very similar issue to what applies to ksh93. Adding new code
without looking at portability creates a fork that make the software hard to
maintain.
> Being in ON would mean, ultimately, that other people could be making
> changes to the source, without a guarantee of the bits being pushed
> "upstream" (though I would really hope any RTI advocate would be savvy
> enough to ask that you were at least included in the code review -- I
> know I would -- but there wouldn't be a *guarantee* that this would happen).
If people like to make changes, they should discuss it first. This is similar
to an Solaris ARC case. Changes must not affect compatibility and should be
aligned with the planned future development.
> > It would be sufficient to write Solaris (ON) specific makefiles for star and
> > the rest of the code.
>
> I've refrained from offering to do so in the past, but if ultimately
> this becomes the major stumbling block, I'll volunteer to help out
> here. As byzantine as ON's build system is, it has become mostly
> familiar to me over the course of time. (Some of the library related
> makefile stuff and CTF support in the kernel still seems like voodoo to
> me, but I seem to be able to manage.)
OK
> > I would need some help for this and a bit more help on how
> > the autoconfiguration stuff may be integrated. I currently believe it
> > should be
> > run at the same time as rpcgen(1) creates some files for /usr/include/.
> >
>
> My strong preference is to avoid use of autoconfiguration in ON if at
> all possible. The reasons for this are:
>
> 1) autoconfiguration significantly increases compile times
This is not true if you do it like I do: one autoconf for all software
and autoconf is controlled by make rules.
> 2) autoconfiguration adds a layer of complexity that makes it harder
> to support if you don't need portability (nothing in ON needs it)
You are correct for the typical free software that follows the GNU autoconf
documentation. My software uses autoconfiguration without adding unneeded
complexity and if you find a bug, you only change a single place and recompile
instead of searching for hundreds of copy/paste locations to fix.
> 3) autoconfiguration can hinder cross-platform portability (c.f. the
> earlier cross-compilation dicussion)
If you take software that has been written in a portable way and try to remove
the portability, you add new bugs and cause the software to be hard to maintain.
I am currently using more than 540 autoconf tests. I am sure you don't like to
check this all by hand.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
