nanogui: Thread: source tree

i think the source tree needs to be tidied up abit with 
a better structure. i am happy to sit down and write
Makefile.am and a configure.in so what we can make the
source tree easier to compile on yet more os'. one
f the reasons being is that i would like to be able to use
nanox + X11 on solaris.

on another note following what i said about the gtk port
i was thinking that it might be an idea to rewrite nanox
to have an api far more similar to X. this means that
it can be completey restructured. this would include using
event structures and window structes etc excatly as
X does. the all anano x calls can be n<X call> and then
have macro substituions on compile time. 

call me mad, but i think this would be a good idea. another
thing, is it worth setting up a nanox/mwin thing on sourceforge
run by VA research? the reason i say this is because we can
have our very own easy to setup cvs server - which means we
can alway devel on the latest source.

chris

======================================================
| Chris Ross ( Boris` )         ####@####.#### |
|                          http://www.darkrock.co.uk |
`----------------------------------------------------' 

On Wed, 15 Dec 1999 12:30:37 +0000 (GMT) you wrote: 
>i think the source tree needs to be tidied up abit with   
>a better structure. i am happy to sit down and write  
>Makefile.am and a configure.in so what we can make the  
>source tree easier to compile on yet more os'. one  
>f the reasons being is that i would like to be able to use  
>nanox + X11 on solaris.  
>  
>on another note following what i said about the gtk port  
>i was thinking that it might be an idea to rewrite nanox  
>to have an api far more similar to X. this means that  
>it can be completey restructured. this would include using  
>event structures and window structes etc excatly as  
>X does. the all anano x calls can be n<X call> and then  
>have macro substituions on compile time.   
 
This has been discussed quite a few times before. 
 
As long as it doesn't increase the size of Nano-X or applications 
using Nano-X, then I'm all for it. However, I still believe that 
to make Nano-X anywhere near source compatible with X, you'd have 
to add a lot of cruft that doesn't belong in a small, compact system. 
 
Vidar Hokstad 
VP R&D, Screen Media AS 

On 15 Dec 1999, Vidar Hokstad wrote:

> This has been discussed quite a few times before. 
>  
> As long as it doesn't increase the size of Nano-X or applications 
> using Nano-X, then I'm all for it. However, I still believe that 
> to make Nano-X anywhere near source compatible with X, you'd have 
> to add a lot of cruft that doesn't belong in a small, compact system. 
>  
> Vidar Hokstad 
> VP R&D, Screen Media AS 
> 

i personally think it's necessary to make is source compatible
so that we can take apps from x and recompile them. that way
we can almost instantly clobber the apps issue and toolkit
issue in one fell swoop. we can also design it such that it can 
be compile with only the necessary chunk that are required.
ie if atoms andhints aren't required then dont compile them in.

this is just my two pence worth.

> i personally think it's necessary to make is source compatible
> so that we can take apps from x and recompile them. that way
> we can almost instantly clobber the apps issue and toolkit
> issue in one fell swoop. we can also design it such that it can 
> be compile with only the necessary chunk that are required.
> ie if atoms andhints aren't required then dont compile them in.

Most X applications are too big to fit a typical nanogui environment. 
A gdk/gtk toolkit port for nanogui with gnome on top does make sense but thats
for a different reason - gnome apps tend to be small but have a _lot_ of
shared libraries. For an embedded system  with a fair number of loadable
apps (eg the palmpilot) you want as much shared toolkit in the base system
rom as possible to keep app size low

Alan

i agree with that but the point of changing the api 
isn't to criupple it's size really to make it more flexible
in the long run. as things like a psion dont really
want alot of x stuff - just small apps, but if we are
running nanox on something with a little more kick to it 
then beefier apps may be wanted... 

chris

======================================================
| Chris Ross ( Boris` )         ####@####.#### |
|                          http://www.darkrock.co.uk |
`----------------------------------------------------' 

On Wed, 15 Dec 1999, Alan Cox wrote:

> > i personally think it's necessary to make is source compatible
> > so that we can take apps from x and recompile them. that way
> > we can almost instantly clobber the apps issue and toolkit
> > issue in one fell swoop. we can also design it such that it can 
> > be compile with only the necessary chunk that are required.
> > ie if atoms andhints aren't required then dont compile them in.
> 
> Most X applications are too big to fit a typical nanogui environment. 
> A gdk/gtk toolkit port for nanogui with gnome on top does make sense but thats
> for a different reason - gnome apps tend to be small but have a _lot_ of
> shared libraries. For an embedded system  with a fair number of loadable
> apps (eg the palmpilot) you want as much shared toolkit in the base system
> rom as possible to keep app size low
> 
> Alan
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

: i think the source tree needs to be tidied up abit with 
: a better structure.

Yes, I agree.  I plan on having that done for 0.87 final,
but I had some submissions (like running on X11) that
everyone got excited about, and I decided to integrate
them first.

Also, Martin has submitted a makefile rewrite
that I plan to use in 0.87.  It creates dependencies
automatically, and also builds a "make xconfig"
that allows different options to be set graphically
under X, rather than editing a makefile.  I am 
looking for a "make config" that does the same
thing, like the Linux kernel.

 i am happy to sit down and write
: Makefile.am and a configure.in so what we can make the
: source tree easier to compile on yet more os'. one
: f the reasons being is that i would like to be able to use
: nanox + X11 on solaris.

Yes, I may take you up on this.  I'd like to add
Martin's submission, and then perhaps you could
look at it from the multiple OS perspective.  BTW,
does running on Solaris mean not using GNU make?


: 
: on another note following what i said about the gtk port
: i was thinking that it might be an idea to rewrite nanox
: to have an api far more similar to X. this means that
: it can be completey restructured. this would include using
: event structures and window structes etc excatly as
: X does. the all anano x calls can be n<X call> and then
: have macro substituions on compile time. 

As others have mentioned, this idea has been discussed
before.  I think I was one of the first to bring it up.
Although I like the idea of making the procedure
calls very close to Xlib's (this is exactly the path
that Microwindows API took), making
the data structures identical will make Nano-X
way too big.  The color model is a perfect example.
X's color model implementation is damn near as big
as all of Nano-X alone.

So, IMHO, realistically, we should look at what API
calls are close and could be made identical, and which
calls will remain different for some time (like color).

Also, at this point, the Nano-X and Microwindows
API's are really in there initial stages.  There's quite a bit
more programming required to make them run the
wide spectrum of calls offered by X11 or Windows.
Perhaps you could send the list a set of concepts
or particular API calls that aren't implemented yet
that need to be.

Regards,

Greg

Chris Ross wrote:

> i think the source tree needs to be tidied up abit with
> a better structure. i am happy to sit down and write
> Makefile.am and a configure.in so what we can make the
> source tree easier to compile on yet more os'. one
> f the reasons being is that i would like to be able to use
> nanox + X11 on solaris.

Like Greg mentioned, I did a rework of the Makefile structure/source
tree. This, however, doesn't use the m4/autoconf stuff. I thought about
using it but found it pretty much overkill for our needs since most of
the supported platforms in nanogui use cross-compiling (linuxCE people
with mips, RTEMS people, us here with ARM, ...) Usually this kind of
mechanism (autoconf) is used to get the configuration of the host it is
run on, not the target platform ... Maybe I'm wrong, but I don't think
the autoconf tools suite is designed to support cross-compiling... What
I did is a configuration mechanism a la linux kernel ...

Regards,

Martin Jolicoeur
GVT Project
####@####.####

On Wed, 15 Dec 1999, Martin Jolicoeur wrote:
> run on, not the target platform ... Maybe I'm wrong, but I don't think
> the autoconf tools suite is designed to support cross-compiling... What

--target=armv4l-linux-gnu

or whatever...

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

I like autoconf for cross-compile environments, and support is explicitly in
autoconf for that.  It's easy to make a site config file that explains the
whole cross-compile environment:

---------
# Brad's config.site for configure
# This is just an example - don't quote me on any of this
CC=mipsel-linux-gcc
CXX=mipsel-linux-gcc
AR=mipsel-linux-ar
RANLIB=mipsel-linux-ranlib
NM=mipsel-linux-nm
ac_cv_path_NM=mipsel-linux-nm
CFLAGS="-msoft-float -s"
CXXFLAGS="-msoft-float -s"
ac_cv_func_setpgrp_void=yes
host=mipsel-linux
prefix=~/mipsel-linux-install

# These are for GNU shellutils
jm_cv_have_proc_uptime=yes
jm_cv_func_working_gnu_strftime=yes
---------

and then say:

    export CONFIG_SITE=~/config.site

before running ./configure.

It works great.  I used to cringe when I saw an autoconf project, but now
that I've figured out this CONFIG_SITE thing (thanks to help from Jay
Carlson) I prefer them.

Regards,
Brad

----- Original Message -----
From: "Martin Jolicoeur" ####@####.####
To: "Chris Ross" ####@####.#### ####@####.####
Sent: Wednesday, December 15, 1999 4:40 PM
Subject: Re: source tree


> Chris Ross wrote:
>
> > i think the source tree needs to be tidied up abit with
> > a better structure. i am happy to sit down and write
> > Makefile.am and a configure.in so what we can make the
> > source tree easier to compile on yet more os'. one
> > f the reasons being is that i would like to be able to use
> > nanox + X11 on solaris.
>
> Like Greg mentioned, I did a rework of the Makefile structure/source
> tree. This, however, doesn't use the m4/autoconf stuff. I thought about
> using it but found it pretty much overkill for our needs since most of
> the supported platforms in nanogui use cross-compiling (linuxCE people
> with mips, RTEMS people, us here with ARM, ...) Usually this kind of
> mechanism (autoconf) is used to get the configuration of the host it is
> run on, not the target platform ... Maybe I'm wrong, but I don't think
> the autoconf tools suite is designed to support cross-compiling... What
> I did is a configuration mechanism a la linux kernel ...
>
> Regards,
>
> Martin Jolicoeur
> GVT Project
> ####@####.####
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>

> -----Original Message-----
> From: Greg Haerr ####@####.####
> Sent: 15 December 1999 15:42
> To: Chris Ross
> Cc: ####@####.####
> Subject: Re: source tree
>
>
> : i think the source tree needs to be tidied up abit with
> : a better structure.
>
> Yes, I agree.  I plan on having that done for 0.87 final,
> but I had some submissions (like running on X11) that
> everyone got excited about, and I decided to integrate
> them first.
>
> Also, Martin has submitted a makefile rewrite
> that I plan to use in 0.87.  It creates dependencies
> automatically, and also builds a "make xconfig"
> that allows different options to be set graphically
> under X, rather than editing a makefile.  I am
> looking for a "make config" that does the same
> thing, like the Linux kernel.

I've got some makefile changes I have been tweaking about with, and some
minor modifications on kbd_tty.c (which need my makefile changes, I plan
to intergrate the changes into kbd_*.c) which I will submit for 0.88 so
I can backport my makefile mods into Martin's. I have made a "make
config" which effectivly calls a chunck of C after compiling it and asks
you questions and fprintf's a makefile.  Hackery but easy.  Again, I'll
intergrate it with Martin's for '88 if you want?

> Yes, I may take you up on this.  I'd like to add
> Martin's submission, and then perhaps you could
> look at it from the multiple OS perspective.  BTW,
> does running on Solaris mean not using GNU make?

No idea about GNU make. It would be easy[1] to write a "makeless" make
system for systems without make.  "make config" makes a shell script,
shell script checks modification dates, if files exist, etc.  Easy once,
a bugger to do if you add/remove/change anything.... Anyone with any
thoughts? (There must be some other Open Source, Small, Dependancy
Related "make" system we can steal, anyone?)

	-Darran