The code, in general, is separated into "common" and "platform" sections,
although there are multiple platform pieces for different components. For
example, the interpreter component has a platform section, the extensions
component has a platform section, etc. There is also a set of components
that can be shared across other components that also have platform
capabilities. These shared components generally implement things like
semaphores, threads, files, etc.
In the common code, platform specific conditional are forbidden. Platform
specific stuff needs to be hidden behind an abstraction layer and
implemented in the platform code. In the platform code, we currently have
just two flavors, windows and unix. The unix code may have platform
specific #ifdefs, if they are small, although in general, we prefer that
sort of conditional stuff be done via the config.h file base on the
presence or absence of apis or header files. If larger changes warrant it,
additional platform directories can always be added for other platforms.
For example, if you have some Mac-specific libraries you'd like to write,
I can see a macos directory getting added to the extensions component.
For install stuff, there is a top-level platform directory where
cross-project files and installer build materials can be placed.
One obvious place where we do have a lot of conditional logic is the
CMakeLists.txt file used by CMake. In general, try to keep the conditional
sections small. For example, rather than have large conditional sections
that accomplish almost the same thing, see if this can be reduced to a
non-conditional with platform-specific variables making modifications.
Rick
Rick
On Wed, Jul 9, 2014 at 11:43 AM, David Ashley <[email protected]>
wrote:
> We are pretty loose about repository access. But there are some rules
> you should know about.
>
> 1. Once a set of files has been copied to a release subdirectory please
> do not modify those files.
> 2. the trunk and branches are always available for updates.
> 3. Stay out of other peoples sandbox subdirectories unless you have
> arranged otherwise with the sandbox owner.
> 4. If a file is strictly for a specific platform then we like to put
> those in a subdirectory like platform/unix for example. I thnk most of
> the Mac stuff has usually been merged into the unix files but if
> something is specific to only the Mac then by all meas create a
> platform/mac (or other name) subdirectory to hold it.
>
> Right now I handle most of the *nix development. Mark handles a lot of
> the Windows stuff (especially ooDialog), and Rick does most of the
> platform independent work. But there are exceptions so ask if you are
> not sure about features you want to work on.
>
> Rick and Mark may have other comments on this.
>
> David Ashley
>
> On Wed, 2014-07-09 at 16:40 +0200, René Jansen wrote:
> > As discussed during the symposium I would like to volunteer for
> supporting ooRexx on OSX - as I obviously see that as an important platform
> to add to the officially supported list.
> >
> > I would like to know which the rules are that I would have to abide with
> and which parts of the repository would be off limits. Of course, being
> familiar with development in larger groups, we do not have to state the
> obvious. I would like to know the rules for platform support - as I
> remember from the beginnings of ooRexx, we would like to support
> capabilities and not just do #ifdefs. I am fine with that. I would think it
> is important to:
> >
> > 1) Have a build for the most recent MacOSX available at all times
> > 2) Test upcoming releases
> > 3) Make sure platform specific functionality works
> >
> > I expect to be able to put some time into that (I regularly build ooRexx
> for own purposes, and have provided installers for past releases).
> > The switch to cmake seems a good moment in time to reinvest some effort
> into building the interpreter and installers, and make sure the MacOSX
> package is not seen as incomplete in comparison to other platforms.
> >
> > Please let me know your opinions and let's see if we can make this work.
> >
> > best regards,
> >
> > René Jansen.
> >
> ------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community
> Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > _______________________________________________
> > Oorexx-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
