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
> > build.sh and cross-compile X.org 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 configure.ac and Makefile.am
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.
(http://mail-index.netbsd.org/tech-pkg/2007/08/18/0002.html)
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
post.
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 - cube%cubidou.net@localhost - cube%NetBSD.org@localhost
"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