Re: Migrating away from using cpp for startx and xinitrc in xinit

[Gaetan Nadon]

On 15-02-10 10:44 AM, Alan Coopersmith wrote:
> Right - build time uses such as startx & xinitrc should be replacable
> with a bit of work, such as Gaetan did in the past to use sed instead
> of cpp on a bunch of man pages.

I had worked on this three years ago. I tried removing the use of cpp as
a "text only" processor every where I could. I had a prototype of what
startx would look like. One has to watch for built-in compiler defines
auch as __APPLE__ and replaced them with Automake variables such as
$host_os assuming the semantic is the same. See attachment.

On a side note, the following lines should be removed as they are left
over  from ancient A/UX 3.0 support.

#ifdef macII
Xrepair
screenrestore
#endif



#!@SHELL_CMD@

#
# This is just a sample implementation of a slightly less primitive
# interface than xinit.  It looks for user .xinitrc and .xserverrc
# files, then system xinitrc and xserverrc files, else lets xinit choose
# its default.  The system xinitrc should probably do things like check
# for .Xresources files and merge them in, startup up a window manager,
# and pop a clock and serveral xterms.
#
# Site administrators are STRONGLY urged to write nicer versions.
#

unset DBUS_SESSION_BUS_ADDRESS
unset SESSION_MANAGER

prefix=@prefix@
exec_prefix=@exec_prefix@
bindir=@bindir@
libdir=@libdir@
host_os=@host_os@

# Check for /usr/bin/X11 and BINDIR in the path, if not add them.
# This allows startx to be placed in a place like /usr/bin or /usr/local/bin
# and people may use X without changing their PATH.
# Note that we put our own bin directory at the front of the path, and
# the standard system path at the back, since if you are using the Xorg
# server theres a pretty good chance you want to bias the Xorg clients
# over the old system's clients.

case $host_os in
*sco* | darwin*)
# First our compiled path
case $PATH in
*:$bindir | *:$bindir:* | $bindir:*) ;;
*) PATH=$bindir:$PATH ;;
esac

# Now the "old" compiled path
case $host_os in
darwin*)
oldbindir=/usr/X11R6/bin
;;
*)
oldbindir=/usr/bin/X11
;;
esac

if [ -d "$oldbindir" ] ; then
case $PATH in
*:$oldbindir | *:$oldbindir:* | $oldbindir:*) ;;
*) PATH=$PATH:$oldbindir ;;
esac
fi

# Bourne shell does not automatically export modified environment 
variables
# so export the new PATH just in case the user changes the shell
export PATH
;;
esac

# Set up the XMERGE env var so that dos merge is happy under X
case $host_os in
*sco*)
if [ -f /usr/lib/merge/xmergeset.sh ]; then
. /usr/lib/merge/xmergeset.sh
elif [ -f /usr/lib/merge/console.disp ]; then
XMERGE=`cat /usr/lib/merge/console.disp`
export XMERGE
fi

userclientrc=$HOME/.startxrc
sysclientrc=${libdir}/sys.startxrc
scouserclientrc=$HOME/.xinitrc
scosysclientrc=@XINITDIR@/xinitrc
;;
*)
userclientrc=$HOME/.xinitrc
sysclientrc=@XINITDIR@/xinitrc
;;
esac

userserverrc=$HOME/.xserverrc
sysserverrc=@XINITDIR@/xserverrc
defaultclient=@XTERM@
defaultserver=@XSERVER@
defaultclientargs=""
defaultserverargs=""
defaultdisplay=":0"
clientargs=""
serverargs=""

case $host_os in
darwin*)
if [ "x$X11_PREFS_DOMAIN" = x ] ; then
export X11_PREFS_DOMAIN=@launchdidprefix@".X11"
fi

# Initialize defaults (this will cut down on "safe" error messages)
if ! defaults read $X11_PREFS_DOMAIN cache_fonts > /dev/null 2>&1 ; then
defaults write $X11_PREFS_DOMAIN cache_fonts -bool true
fi

if ! defaults read $X11_PREFS_DOMAIN no_auth > /dev/null 2>&1 ; then
defaults write $X11_PREFS_DOMAIN no_auth -bool false
fi

if ! defaults read $X11_PREFS_DOMAIN nolisten_tcp > /dev/null 2>&1 ; 
then
defaults write $X11_PREFS_DOMAIN nolisten_tcp -bool true
fi

# First, start caching fonts
if [ x`defaults read $X11_PREFS_DOMAIN cache_fonts` = x1 ] ; then
if [ -x $bindir/font_cache ] ; then
$bindir/font_cache &
elif [ -x $bindir/font_cache.sh ] ; then
$bindir/font_cache.sh &
elif [ -x $bindir/fc-cache ] ; then
$bindir/fc-cache &
fi
fi

if [ -x @XINITDIR@/privileged_startx ] ; then
# Don't push this into the background becasue it can cause
# a race to create /tmp/.X11-unix
@XINITDIR@/privileged_startx
fi

if [ x`defaults read $X11_PREFS_DOMAIN no_auth` = x0 ] ; then
enable_xauth=1
else
enable_xauth=0
fi

if [ x`defaults read $X11_PREFS_DOMAIN nolisten_tcp` = x1 ] ; then
defaultserverargs="$de

Re: Migrating away from using cpp for startx and xinitrc in xinit

[Alan Coopersmith]

On 02/10/15 05:01 AM, Matthieu Herrb wrote:

In the case of startx / xinitrc I think it is possible to get rid of
cpp without too much difficulty. It's doing static substitutions at
build time only.

The case of xrdb is more problematic. There the use of cpp to
preprocess resources files at run time is a feature (and it depends on
a "traditional" pre-processour). For this case using tradcpp (pointed
out by Thomas Klausner further down this thread) is indeed the way to
go.


Right - build time uses such as startx & xinitrc should be replacable
with a bit of work, such as Gaetan did in the past to use sed instead
of cpp on a bunch of man pages.

I think we're pretty much stuck with the runtime calls in xrdb & imake
though.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Migrating away from using cpp for startx and xinitrc in xinit

[Matthieu Herrb]

On Tue, Feb 10, 2015 at 12:40:32AM -0800, Jeremy Huddleston Sequoia wrote:
> 
> > On Feb 10, 2015, at 00:35, Hans de Goede  wrote:
> > 
> > Hi,
> > 
> > On 10-02-15 08:39, Jeremy Huddleston Sequoia wrote:
> >> It seems that using cpp for startx and xinitrc in the xinit port is coming 
> >> back to bite us now as different C preprocessors don't exactly process 
> >> non-C files in ways that we might want.
> >> 
> >> https://trac.macports.org/ticket/46811#comment:4
> >> 
> >> Does anyone have any strong opinions about this state of affairs and how 
> >> we should address it?  If not, I'll mull it over for a while and try to 
> >> figure something out.
> > 
> > startx is quite fragile, I think it may be best to just fix things
> > so that they do work with the cpp from llvm, e.g. replace the #
> > comments with /* ... */ comments might be all that is necessary.
> 
> My experience (failing) to get xmkmf/imake working with llvm's cpp
> makes me see this as a weak link that should be more properly dealt
> with rather than just patched up with more duct tape. 

In the case of startx / xinitrc I think it is possible to get rid of
cpp without too much difficulty. It's doing static substitutions at
build time only.

The case of xrdb is more problematic. There the use of cpp to
preprocess resources files at run time is a feature (and it depends on
a "traditional" pre-processour). For this case using tradcpp (pointed
out by Thomas Klausner further down this thread) is indeed the way to
go.

-- 
Matthieu Herrb
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Migrating away from using cpp for startx and xinitrc in xinit

[Thomas Klausner]

On Tue, Feb 10, 2015 at 08:04:05PM +0900, Carsten Haitzler wrote:
> On Mon, 9 Feb 2015 23:39:06 -0800 Jeremy Huddleston Sequoia
>  said:
> 
> > It seems that using cpp for startx and xinitrc in the xinit port is coming
> > back to bite us now as different C preprocessors don't exactly process non-C
> > files in ways that we might want.
> > 
> > https://trac.macports.org/ticket/46811#comment:4
> > 
> > Does anyone have any strong opinions about this state of affairs and how we
> > should address it?  If not, I'll mull it over for a while and try to figure
> > something out.
> 
> we had this problem long ago and solved it by shipping our own cpp:
> 
> http://git.enlightenment.org/core/efl.git/tree/src/bin/edje/epp
> 
> it's not actually "ours" - it's an ancient stand-alone gpl stand-alone cpp 
> that
> we KNOW works and outputs exactly what we expect/want. you could do the same.

There's also another similar project, tradcpp by dholl...@netbsd.org,
distfile at
http://ftp.NetBSD.org/pub/NetBSD/misc/dholland/tradcpp-0.4.tar.gz
 Thomas
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Migrating away from using cpp for startx and xinitrc in xinit

[The Rasterman]

On Mon, 9 Feb 2015 23:39:06 -0800 Jeremy Huddleston Sequoia
 said:

> It seems that using cpp for startx and xinitrc in the xinit port is coming
> back to bite us now as different C preprocessors don't exactly process non-C
> files in ways that we might want.
> 
> https://trac.macports.org/ticket/46811#comment:4
> 
> Does anyone have any strong opinions about this state of affairs and how we
> should address it?  If not, I'll mull it over for a while and try to figure
> something out.

we had this problem long ago and solved it by shipping our own cpp:

http://git.enlightenment.org/core/efl.git/tree/src/bin/edje/epp

it's not actually "ours" - it's an ancient stand-alone gpl stand-alone cpp that
we KNOW works and outputs exactly what we expect/want. you could do the same.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Migrating away from using cpp for startx and xinitrc in xinit

[Daniel Stone]

Hi,

On Tuesday, February 10, 2015, Jeremy Huddleston Sequoia <
jerem...@freedesktop.org> wrote:

> It seems that using cpp for startx and xinitrc in the xinit port is coming
> back to bite us now as different C preprocessors don't exactly process
> non-C files in ways that we might want.
>
> https://trac.macports.org/ticket/46811#comment:4
>
> Does anyone have any strong opinions about this state of affairs and how
> we should address it?  If not, I'll mull it over for a while and try to
> figure something out.
>

Nothing new under the sun ...

 https://bugs.debian.org/339683


The general conclusion seemed to be 'yeah, don't do that'. Actual users
relied on the cpp parsing so we couldn't change that, sadly. So just keep
using a normal preprocessor.

Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Migrating away from using cpp for startx and xinitrc in xinit

[Jeremy Huddleston Sequoia]

> On Feb 10, 2015, at 00:35, Hans de Goede  wrote:
> 
> Hi,
> 
> On 10-02-15 08:39, Jeremy Huddleston Sequoia wrote:
>> It seems that using cpp for startx and xinitrc in the xinit port is coming 
>> back to bite us now as different C preprocessors don't exactly process non-C 
>> files in ways that we might want.
>> 
>> https://trac.macports.org/ticket/46811#comment:4
>> 
>> Does anyone have any strong opinions about this state of affairs and how we 
>> should address it?  If not, I'll mull it over for a while and try to figure 
>> something out.
> 
> startx is quite fragile, I think it may be best to just fix things
> so that they do work with the cpp from llvm, e.g. replace the #
> comments with /* ... */ comments might be all that is necessary.

My experience (failing) to get xmkmf/imake working with llvm's cpp makes me see 
this as a weak link that should be more properly dealt with rather than just 
patched up with more duct tape.




smime.p7s
Description: S/MIME cryptographic signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Migrating away from using cpp for startx and xinitrc in xinit

[Hans de Goede]

Hi,

On 10-02-15 08:39, Jeremy Huddleston Sequoia wrote:

It seems that using cpp for startx and xinitrc in the xinit port is coming back 
to bite us now as different C preprocessors don't exactly process non-C files 
in ways that we might want.

https://trac.macports.org/ticket/46811#comment:4

Does anyone have any strong opinions about this state of affairs and how we 
should address it?  If not, I'll mull it over for a while and try to figure 
something out.


startx is quite fragile, I think it may be best to just fix things
so that they do work with the cpp from llvm, e.g. replace the #
comments with /* ... */ comments might be all that is necessary.

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Migrating away from using cpp for startx and xinitrc in xinit

[Jeremy Huddleston Sequoia]

It seems that using cpp for startx and xinitrc in the xinit port is coming back 
to bite us now as different C preprocessors don't exactly process non-C files 
in ways that we might want.

https://trac.macports.org/ticket/46811#comment:4

Does anyone have any strong opinions about this state of affairs and how we 
should address it?  If not, I'll mull it over for a while and try to figure 
something out.




smime.p7s
Description: S/MIME cryptographic signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel