Hi Everybody,
I just wanted to give an outline of the source tree reorganization I'm planning after
the 0.44 release. This is necessary in my opinion for several reasons:
- The current build system is hard to port to non-linux platforms
- A lot of the code in CVS is arranged in a less than logical way
- The configuration system is hard to cross-compile with for people who
aren't familiar with all the GNUisms involved
- The configuration system doesn't handle dependencies
- The configuration system only configures pgserver
The reorganization I have planned would involve two major changes: moving the source
tree to a Subversion server outside of sourceforge, and switching the build system,
probably to something based on SCons. This subversion server has about 40GB of
redundant
storage, a 256kbps internet connection, and I'll be able to make offsite backups
regularly. Releases will still be done through sourceforge.
The big concepts I want to emphasize with the new system are portability, and
configuration of picogui as a complete system. The directory tree will look something
like this:
------8<------
- picogui
- README, COPYING, INSTALL...
- build (Intermediate files in compilation)
- x86-dev
- arm-zaurus
- ppc-dev
...
- bin (final compiled binaries)
- theme
- x86-dev
- arm-zaurus
- ppc-dev
...
- config (files for the configuration system)
- fonts
- src (clean source tree)
- pgserver
- appserver
- lib
- c
- client
- media
- python
- PicoGUI
- cpp
...
- tools
- themec
- themedc
- future app packaging tools
- apps
- Only relatively usable apps (pgedit, pterm, scribble, working games...)
- devapps
- Apps that are only useful for developers
- themes
- Relatively usable themes, in their own directories
- devthemes
- Themes only interesting to developers
------>8------
This new source tree layout emphasizes PicoGUI as a complete system. It removes a lot
of the confusing things about the old tree:
- the cli_* naming convention for libraries will be gone, since it can be confusing.
The new source tree uses directories to organize libraries by language, and the
library should be called the "C client" rather than "cli_c"
- Clean up the awful mess in themetools/examples. Themes will separated into
generally
useful and developers-only, and each theme's source will be in a separate
directory.
Since svn allows moving source trees easily, themes could be very simply migrated
between the categories.
- Separate applications into mostly usable, and for developers only
The new configuration system will still be similar to the current one, but with a few
key differences:
- It will configure the entire source tree, not just pgserver. Every component will
be conditionally compiled depending on this configuration
- Dependencies will be managed for the whole system. Outside libraries (libpng, zlib,
SDL, etc.) will be represented as targets in the config system, as will 'tasks'
that select common options for different situations. The operating environment
(OS and available libraries) for the target platform will be automatically
detected.
- Cross compilation can be managed by selecting a different target platform in the
config system. It would still support specifying the compiler and paths manually,
but this would remove the pain from cross-compiling to common platforms.
- Once picogui has app packaging, it will integrate with the config system to provide
automatic installation of the completed picogui system into a distro.
- There will be many frontends. If you're only selecting a task or two, you could use
the command line. There could be graphical configuration frontends for ncurses,
gtk,
or PicoGUI. You could even have frontends that would glue this system to other
config systems, like the ones OpenZaurus or Smartdata use.
- The config system will make it clear which options you selected manually, and which
are implicitly selected by a dependency. This will make it easy to avoid using
compile-time options that aren't necessary, so you can make the smallest binary
possible.
For example, you could start with a blank configuration, then add a "OpenGL game UI"
task, which would include all the widgets, drivers, and vidlibs you would need for
that.
Or you could include a "Zaurus" task that would build the drivers the Zaurus needs,
plus
a "PDA environment" task that would build common applications. It would automatically
resolve what vidlibs those drivers need, and what libraries those applications need.
--Micah
--
Only you can prevent creeping featurism!
-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel
