Notice: We have migrated to GitLab launching 2024-05-01 see here: https://gitlab.rtems.org/

Changes between Version 145 and Version 146 of Developer/OpenProjects


Ignore:
Timestamp:
01/26/10 04:15:56 (14 years ago)
Author:
JoelSherrill
Comment:

/* Development Environment Oriented */ More shortening

Legend:

Unmodified
Added
Removed
Modified
  • Developer/OpenProjects

    v145 v146  
    200200 *  Implement a cross-platform [wiki:Projects/GSoC/ApplicationConfigurationGUI  Application Configuration GUI].
    201201 *  Improve [wiki:Projects/GNUToolsTesting  Testing of the GNU Tools] on RTEMS targets
    202  *  TBD Move other descriptions to their own page and list here.  Shorten master page.
    203 = RTEMS Tool Support on Debian =
    204 
    205 
    206 '''Status:'''  Packaging generated as a GSOC 2008 project.  Needs to be "templatized" to minimize duplication and then production Debian packaging build infrastructure established similar to the one for RPMs and MinGW binaries.
    207 
    208 Pre-compiled versions of the RTEMS tools are currently available for RPM-based GNU/Linux distributions such as Fedora, RedHat Enterprise
    209 Linux, CentOS, and SUSE as well as MS-Windows via MinGW.  This project consists of the development of comparable .deb package specifications
    210 and build scripts.  The resulting packaging and infrastructure should be suitable for at least GNU/Debian and Ubuntu distributions.  As the
    211 RTEMS toolset updates frequently, there must be scripting infrastructure developed to build these tools easily when updates are required.
    212 
    213 [wiki:RalfCorsepius RalfCorsepius] is the RPM builder and maintainer.  He uses Mock to use a single development machine to build binaries for a variety
    214 of distributions.  He is a good resource or mentor for this project.
    215 
    216 The RTEMS Project currently does not have a computer running a Debian based GNU/Linux distribution and would have to have one
    217 before these could be supported long term.
    218 = RTEMS Tool Support on MacOS =
    219 
    220 
    221 '''Status:''' No active volunteers.
    222 
    223 The goal of this project is to provide precompiled versions of the
    224 RTEMS tools for Mac OS X.  As the RTEMS toolset updates frequently,
    225 there must be scripting infrastructure developed to build these tools
    226 easily when updates are required.
    227 
    228 Tool distribution questions:
    229  *  Provide Binary installers for all of the tools ( similar to the Windows MingW binaries ) ?
    230  *  Provide Mac Ports ( http://www.macports.org ) for the tools ? ( and can these be used for BSD variants too? ) ?
    231  *  Provide Fink .deb packages ( http://www.finkproject.org/ ) ?
    232  *  Or just provide an easy to use shell script that can download, patch, build and install the tools?
    233 
    234 Mac OS X version/architecture questions:
    235  *  Does the project make a cut-off with a newer version of OS X ( say 10.4 or even 10.5 )?
    236  *  Does the project support x86 and PPC Macs or just stick with x86?
    237 
    238 Build questions:
    239  *  Can the tools be built and packaged on an open source Darwin OS machine? or is a full Mac OS X machine needed to do these builds?
    240 
    241 License questions:
    242 Little is know by those who currently build RTEMS tool binaries about
    243 the packaging and legal requirements associated with providing
    244 MacOS binaries.
    245 
    246 The RTEMS Project currently does not have a MacOS X computer and would
    247 have to have one before these could be supported long term.
    248 = GNU Java =
    249 
    250 
    251 '''Status:''' No active volunteers.
    252 
    253 The purpose of this project is to make the [http://gcc.gnu.org/java/ GJC (GNU Java Compiler)] work with RTEMS.  RTEMS is supported as a target in GCC so it is expected that the primary development focus of this project will be to adapt the run-time library to RTEMS.  Since the GNU Ada and C++ run-times are already ported to RTEMS, there are examples to work from for many issues.  Also if the porter assumes it is using the POSIX thread interface, it is very likely that the GNU/Linux port will be a good reference.
    254 
    255 This project will consist of the following phases:
    256 
    257  *  Port GJC Run-time to RTEMS.  The port will be target CPU architecture independent.  Just like the GNU Ada tasking support, this should be written in a processor architecture manner using portable API calls provided by RTEMS.
    258  *  Run GJC Test Suite.  We are already running the general GCC C/C++ testsuite and the Ada run-time tests.  So there is precedence and help available.
    259  *  Submit modifications to GCC and RTEMS Projects
    260 
    261 Here is a list of technical details from Tom Tromey, the GCJ maintainer.  A lot of stuff in libgcj is optional.  So, a minimal port can be made pretty quickly.  From memory:
    262 
    263  *  The GC must be ported.  This can be difficult but usually is not, since it has already been widely ported.
    264  
    265  *  For a good libgcj port, libffi must be ported.  It already runs on most architectures though.  This would only matter if the target is a new architecture or if the target has a different ABI.  A libffi port has two parts.  Each is optional.  First, the normal libffi API is used for reflection and one direction of JNI.  Second, the libffi closure API is used for the interpreter and JNI->Java calls.  libgcj will configure and build just fine if these are missing.
    266 
    267  *  For an excellent libgcj port, you have to write code to turn a signal into an exception.  This is some hairy unwinding stuff, partly in gcc and partly in libgcj.  However, there is an option to have gcj add explicit checks where needed, for platforms where this is not possible.  [NOTE from joel:  This is the technique also used by GNU Ada so there should be existing code to leverage and share between the GNAT/RTEMS port and the GJC/RTEMS port.]
    268 
    269  *  libgcj's thread layer must be ported.  This is usually easy.  The POSIX "flavor" already works in a lot of places.  Note that this can affect the GC as well.   This part can actually be disabled, but you can't run much java code without threads.
    270 
    271  *  File I/O, sockets, and other stuff like that should be ported.  Some of this can be disabled for less-capable targets.  Again, the POSIXy code should work fine.
    272 
    273  *  For the full pull, port AWT.  This is a lot of work and, really, nobody ever bothers.
    274 
    275 There was a previous effort to do this but it was not submitted to the GCC Maintainers.  At this point, it was against such an old version of gcc that it would probably have to be used as a reference more than a code base.
    276 
    277 This is expected to be a good [wiki:GSoC  Google Summer of Code] project. 
    278 
    279 The contributor MUST have or file Free Software Foundation paperwork and it is assumed that this code will be contributed to GCC.
     202 *  Complete implementation of [wiki:Building/DebianHostedTools  Debian Packages].
     203 *  Prebuilt [wiki:TBR/Delete/MacOSHostedTools MacOS tools]
     204 *  RTEMS port of the [wiki:Projects/GNUJavaCompiler  GNU Java Compiler (gjc)]
     205
     206 *  TBD Move other descriptions to their own page and list here.  Shorten master page.
    280207= eVisual Studio Integration =
    281208
     
    290217[wiki:ChrisJohns ChrisJohns] is a good resource for this project because he is
    291218the maintainer for the RTEMS MinGW hosted tools
    292 
    293219= =ArgoUML for RTEMS ==
    294220