Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Native X.Org: testers wanted

On Mon, Sep 22, 2008 at 02:36:14PM -0500, Eric Haszlakiewicz wrote:
> On Mon, Sep 22, 2008 at 04:44:08PM +0200, Quentin Garnier wrote:
> > On Mon, Sep 22, 2008 at 09:50:37AM -0400, Izaac wrote:
> > > On Mon, Sep 22, 2008 at 03:50:06AM +0300, Cem Kayali wrote:
> > > > I use modular Xorg from pkgsrc, and i would like to know advantages  
> > > > and/or important differences between mentioned native Xorg and modular  
> > > 
> > > None.  Rather than take advantage of the possibility of finally
> > > divorcing the optional graphics subsystem into the framework for
> > > optional subsystems, i.e. pkgsrc, we're now apparently maintaining
> > > the same software in two places.
> > 
> > Please point me to your patches that enable us to use pkgsrc from
> > and cross-compile from about any POSIX system.  I
> > really won't mind flushing down the toilets rtr and mrg's work
> > because I feel the same as you do.  And I'm pretty sure they wouldn't
> > mind that the pkgsrc people would be the only ones maintaining X.Org.
> > 
> > Oh, wait, maybe you were just being snotty.
> I thought there already were several packages in pkgsrc to help with 
>  doing cross compilation.  Do those do anything beyond just building
>  an appropriate compiler?  
> Once you have the tools built, isn't it just a matter of setting 
> CC=$TOOLDIR/<foo>-gcc, and telling pkgsrc to install into a separate destdir?

It's slightly more complicated, for two reasons:

  - in base, we have complete control over what the toolchain is (i.e.,
    the set of TOOL_<tool> variables, along with the set of
    HOST_<utility> for various tasks).

    In pkgsrc this is not the case:  the exact toolchain varies from
    package to package, some packages being themselves part of the
    toolchain for others.

    Moreover, while currently pkgsrc has the notion of "build"
    dependencies, it lacks the difference between a target build
    dependency (i.e., a library archive, header files) and a host build
    dependency (tools that are run during the build).

    It's not that pkgsrc is totally ignorant about those things, far
    from it, but it's just not possible right now to do cross
    compilation easily.

  - a lot of packages are not friendly to cross-compilation.  While it's
    probably not the case of most FSF programs, I'm fairly certain that
    is a non-trivial task to make all of the X.Org packages friendly to
    cross-compilation.  Writing proper and
    files is not an easy thing, and not even all X.Org packages use
    autotools.  Have a look at the build framework of MesaLib (beware
    for your sanity, though).

So yes, in theory it doesn't seem a terrible challenge, but the real
world is here to remind you that theory remains theoretical.

Did you guys notice my use of the word "unfortunate" in my initial post?
If you think I am happy with this situation, you can ask anyone I have
discussed it with the past few months;  they'll tell you I am not.

> Since no-one has done it yet, there's probably more to do, but I don't have 
> much of an idea of what beyond pointing at the right C compiler would be 
> necessary, so when I hear someone say "I did a bunch of work to import X 
> again"
> it really sounds like amount of work it take to do that outweighs what it 
> would take to get it working in pkgsrc.

Actually, someone has tried.  It was the subject of a Google Summer of
Code project in 2007.


The first issue is that this mechanism needs maintainance which, as far
as I can't tell, hasn't been done ever since it was in a working state.

The main issue however, is that it requires X.Org to be already
installed in the host system, which is a huge constraint, especially
given our lack of infrastructures to properly distribute binary
packages.  I think there are a few other caveat not listed in that

The state of X11 in base has been on core's mind for a while now, and
someone (namely Matthew Green) finally stepped up and did work so we
could have a binary distribution of X.Org with 5.0 on architectures
where it matters to have a modern enough X server.

You may or may not like the way it is done, but at least someone has
done something so we could move forward, and I am very grateful to
Matthew for that.

Quentin Garnier - -
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgpR0Q7FNY4yL.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index