Modularization mailing list and initial strawman proposal

[Adam Jackson]

On Friday 18 March 2005 15:39, Roland Mainz wrote:
> Additionally there is the question whether all platforms supported by
> Imake are supported or can be supported by design (OpenVMS and QNX come
> in mind where "autoconf" support can only be described as poor ...).
> What should we do here ? The worst case would be that X.org quickly
> becomes "upstream" for autoconf support on these platforms... =:-)

One has to question whether these platforms have sufficient interest within 
the OSS community to worry about supporting them.  Also, mentioning OpenVMS 
is a bit disingenuous, we don't support that anyway.

> What happens if the maintainers of these platforms do not have the
> resources (e.g. time) to do the transition ? The Imake and Imakefiles
> exist since many many years and it is VERY unlikely that we can expect
> to pull over all changes to all platforms within just ... say... three
> months (assuming the X11R7 release should appear in summer 2005). That's
> pretty much impossible.

They don't have to do it now.  They can do it by 7.1.  Remember that an 
imake-based 6.9 is part of the plan.  Presumably if no one steps up to 
contribute support for a given platform, then no one cares about that 
platform.

I appreciate the desire to keep as many platforms working as possible, but 
it's incorrect to think that simply shipping the set of build options for 
platform Z that happened to work in 1985 will work for platform Z++ now.

> >    Autodetection can add dependencies that you didn't intend. For
> >    example, a developer may have a library on their build system that
> >    isn't available on the target system.
> >      * Dependencies will be explicitly listed and documented. Configure
> >        options will be used to control which dependencies are enabled or
> >        disabled.
>
> How many "configure" options will that be ? 50... 100... 200 ? It may be
> better to look into a way of a config file a lá xc/config/cf/host.def to
> avoid having giant command lines which call "configure" (mozilla has a
> non-standard solution which may be adoptable in this case).

How many imake options do we have?  Quantity of options is not the issue.  
Sensible defaults is the issue.

We will have many fewer options per package than we currently have with imake, 
because each package will be smaller and thus won't have the full set of 
compile-time flags.  But autoconf really does make this easy, by ignoring 
flags it doesn't know about.  So you can do something like:

$ top=$(pwd)
$ cat > configure-options << EOF
--with-xinerama
--without-glx
--enable-debug
EOF
$ echo --config-cache=$top/config.cache >> configure-options
$ for i in $(cat build-order) ; do
> pushd $i
> ./configure $(cat $top/configure-options)
> make 
> sudo make install 
> popd
> done

No problem.

> >    By default, all libraries are built as shared objects; however, with
> >    other build options, static, profiled and debug versions can be built.
>
> What about libraries which "unstable" APIs which are currently build as
> "static" versions for that reason (XprintUtils comes in mind from my
> side) ? And what about helper libraries which are currently used to
> build the Xserver ?

Those "unstable" libraries are, by definition, not shippable.  Either you're 
stable enough to be included in the release - in which case, formalize your 
API and tag it with a 1.0 soversion - or you're not.

.a files created during the compilation of the server do not count as 
libraries for purposes of this discussion.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-modular/attachments/20050321/1ece2162/attachment.pgp