4:54 p.m.
Now that X.Org X11R7 has been autotooled and no longer uses imake
as a build system, imake is more or less deprecated by X.Org. This
means it is about to become a second class citizen overall, and
eventually is likely to just die.
X.Org does plan on modularizing imake as part of X11R7 however, in
order to provide some compatibility for a few releases, however to
the best of my knowledge the current state of imake modularization
is not useable by 3rd party packages for building, although it will
likely become more useable as X11R7 nears.
I'm sending out this email both to alert and warn 3rd party package
developers that Imake is slowly being deprecated, and to seek
volunteers to find packages in Fedora Core, Fedora Extras, and
other 3rd party rpm repositories which depend on imake at build
time, and report them in the following Red Hat tracker bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169208
If the package is part of Fedora Core or Extras and uses imake for
building, please also report a bug against that package in bugzilla,
so that the package maintainers are aware their packages may fail
to build with X11R7, and may need updates to continue building, or
may need to switch to GNU autotools.
Thanks in advance to any volunteers who step forward to help out
with this X11R7 modularization effort.
TTYL
5:01 p.m.
On Saturday 24 September 2005 17:54, Mike A. Harris wrote:
Now that X.Org X11R7 has been autotooled and no longer uses imake
as a build system, imake is more or less deprecated by X.Org. This
means it is about to become a second class citizen overall, and
eventually is likely to just die.
Imake the program or imake the package? I haven't seen any new software using
imake in a long time but several programs using makedepend comes to my mind.
If you search you'll find a lot more hits on google for makedepend than for
imake :-)
Peter.
5:42 p.m.
Peter Arremann wrote:
On Saturday 24 September 2005 17:54, Mike A. Harris wrote:
>Now that X.Org X11R7 has been autotooled and no longer uses imake
>as a build system, imake is more or less deprecated by X.Org. This
>means it is about to become a second class citizen overall, and
>eventually is likely to just die.
Imake the program or imake the package?
Both. "imake" the program did not used to have a package before, so
the two are one and the same. The difference is that in the modular
tree, imake the program is now in it's own package standalone, like
everything else in the modular tree.
I haven't seen any new software using imake in a long time but
several
programs using makedepend comes to my mind.
I believe this is true, that people are no longer using imake for
new software projects. However that isn't a problem to solve as
it solves itself already.
The problem that I'm trying to solve right now, is that existing
software out there does indeed use imake during build, and will
break if it goes away. That's the stuff we want to find. I suspect
that there are probably a fair number of oldish Motif/Xt/Xaw
applications out there currently that use imake to build with, and
will fail soon.
If you search you'll find a lot more hits on google for
makedepend than for
imake :-)
That may be so, but that is an orthagonal issue which is not even
a problem, considering that makedepend is already provided in the
X modular tree and is fully useable.
Just to be clear - this request is strictly about imake and nothing
else.
Thanks in advance.
6:47 p.m.
On Sat, September 24, 2005 6:42 pm, Mike A. Harris said:
The problem that I'm trying to solve right now, is that existing
software out there does indeed use imake during build, and will
break if it goes away. That's the stuff we want to find. I suspect
that there are probably a fair number of oldish Motif/Xt/Xaw
applications out there currently that use imake to build with, and
will fail soon.
I'm wondering if you can simply nuke it from rawhide and try a
full rebuild -- would that generate a useful list of apps?
This may not be easily doable with the current build system,
but it seems worth a try if it is.
--
Dimi
8:52 p.m.
New subject: fedora-d-rh] Re: Request for volunteers: Find packages that rely on imake
On Sat, 24 Sep 2005, Mike A. Harris wrote:
The problem that I'm trying to solve right now, is that existing
software out there does indeed use imake during build, and will
break if it goes away. That's the stuff we want to find. I suspect
'gv' requires imake, to build, right off the top of my head.
But it is in my head, because I heard the 'warning' at
Ottawa's x.org BoF ;) and so went looking through packages I
use and rely on; 'ggv' just doesn't come near 'gv' for
usability or speed)
Repositories with hits:
Altlinux
Fedora
Netwinder
OpenNA
Red Hat
Checking my SRPM archives (14547 packages) with a semi-smart
scriptlet, I find these candidates:
awemidi (Alt)
Canna
cernlib (Alt)
fvwm (Netwinder)
glut (Netwinder)
gv
libxview (Alt)
mgetty (Alt)
mxp (Netwinder)
openmotif (Netwinder)
speyes (Alt)
synaptics
transfig
x2x
x3270 [ouch - I use this -- will test further]
Xaw3d (Netwinder)
xfig
xfishtank (Alt)
xforms (Alt) [the LyX component]
XFree86 (duhhh)
xgammon (Alt)
xjewel (Alt)
XmHTML (Alt)
xpm (Alt)
xtoolwait (Alt)
-- Russ Herrold
9:42 p.m.
New subject: fedora-d-rh] Re: Request for volunteers: Find packages that rely on imake
On Sat, 2005-09-24 at 21:52 -0400, R P Herrold wrote:
On Sat, 24 Sep 2005, Mike A. Harris wrote:
Checking my SRPM archives (14547 packages) with a semi-smart
scriptlet, I find these candidates:
-- Russ Herrold
Can you post your script?
-dtf
11:42 a.m.
New subject: Request for volunteers: Find packages that rely on imake
On Sat, 24 Sep 2005, David Farning wrote:
On Sat, 2005-09-24 at 21:52 -0400, R P Herrold wrote:
> On Sat, 24 Sep 2005, Mike A. Harris wrote:
> Checking my SRPM archives (14547 packages) with a semi-smart
> scriptlet, I find these candidates:
Can you post your script?
I wiped it, but it was like this:
#!/bin/sh
BASED="/var/ftp/pub"
for i in `find $BASED -name '*src.rpm'`; do
#
# Note: our default build point (customarily ~/rpmbuild/BUILD/ )
# is relocated into a local FS /var/tmp, to
# avoid NFS build collision and time skew issues
rm -rf ~/rpmbuild/SOURCES/* ~/rpmbuild/SPECS/* /var/tmp/*
rpm -U $i 2>/dev/null
IMA=`grep -i imake ~/rpmbuild/SPECS/* 2> /dev/null`
rpmbuild -bp `find ~/rpmbuild/SPECS/ -name '*spec'`
cd /var/tmp
NONCE=`egrep -R 'xmkmf' * 2> /dev/null`
[ "x$NONCE" != "x" -o "x$IMA" != "x" ]
&& {
SHRT=`basename $i`
echo "$SHRT $i "
echo "$IMA "
echo "$NONCE "
echo " "
}
done
and then manually scanning the results
-- Russ Herrold
1:53 p.m.
On Sat, 2005-09-24 at 17:54 -0400, Mike A. Harris wrote:
Now that X.Org X11R7 has been autotooled and no longer uses imake
as a build system, imake is more or less deprecated by X.Org. This
means it is about to become a second class citizen overall, and
eventually is likely to just die.
What's the equivalent of using the SDK in the new X.Org world?
How is an external driver for X (eg synaptics) supposed/recommended to
maintain compatibility with old/new build methods?
Paul
2:39 a.m.
Paul Nasrat wrote:
On Sat, 2005-09-24 at 17:54 -0400, Mike A. Harris wrote:
>Now that X.Org X11R7 has been autotooled and no longer uses imake
>as a build system, imake is more or less deprecated by X.Org. This
>means it is about to become a second class citizen overall, and
>eventually is likely to just die.
What's the equivalent of using the SDK in the new X.Org world?
How is an external driver for X (eg synaptics) supposed/recommended to
maintain compatibility with old/new build methods?
All of the drivers are external and use the sdk now, which is
generated by the xorg-x11-server src.rpm into the subpackage
"xorg-x11-server-sdk". The directory paths, et al. are
queryable via pkg-config.
More or less works the same way as before, only more automateable
now and slightly more flexible.
What would be nice, would be to get VNC using the SDK instead of
it's own full copy of the entire source. ;)
6786
days inactive
6789
days old
8 comments
6 participants
participants (6)
-
David T Farning -
Dimi Paun -
Mike A. Harris -
Paul Nasrat -
Peter Arremann -
R P Herrold