On Thu, 6 Nov 2003, T Ingham wrote:
While this drum has been pounded firmly in the past, what sort of position does the new dev team have toward keeping the source base runnable on OSX? I saw that Mac OS was listed on the project page, but Sodipodi has had issues in the past compiling for XFree on older OSX releases.
So far we've been doing development on linux, but we did talk about this. Portability is a Good Thing.
The tradeoffs we will be facing are between being able to easily build on other platforms and being able to take advantage of third-party libraries that may or may not be supported on those platforms.
The reason we want to increase use of third party libraries is that if we can reduce the amount of code we're responsible for, then we can focus on making that chunk we *are* responsible for better, more complete, and of higher quality, and leave those other bits to others. There are currently over 100,000 lines of code, and several of our architectural changes aim at cutting that count down.
I expect this is going to be an ongoing discussion and we're going to need advocates (and especially developers) on those platforms to keep us on track. For example, we won't necessarily know if we've broken platform support until someone checks and tells us.
There are other significant downsides to increasing use of third party lib's that make them a bit of a hassle. But the hope is that by overcoming those challenges and contributing our fixes to the common libs, we can help gain better functionality for a lot of other open source projects in the process.
We'll have to see how it works. This strategy has lots of challenges to it, but sharing is really the Right Thing to Do.
So, where this line of thinking leads is this: We shouldn't let platform dependence issues stay our hand from adopting good libraries, but rather strive to be good about passing info/patches/bug reports upstream to those libs to get *them* to support the platform too. That will be harder than just choosing not to use the lib, but consider that it achieves wider benefit to the platform.
It would be good for folks on non-Linux platforms to do some trailblazing by looking at the lib's on our roadmap that we're considering and seeing if they work for that platform, and if not appraising the effort to get them to work. Obviously we won't be adopting them overnight, so there's time for people to work on them, so by the time we get there, their adoption will cause no problems.
Now, the *real* solution to this whole problem is to establish a regression testing environment. We'll be talking about that more in the future.
I'm attempting a build now as I'm writing this, so the answer may already be a moot point.
Another issue we may run into is that unlike C, C++ is not everywhere the same, and we can expect some issues as we try using different compilers. Fortunately that's not a showstopper, it'll just take some effort from folks to identify those problems and send in the fixes.
We took out the Visual C++ (IIRC) project file from the codebase because switching the name of the app mussed things up. I'm not even sure if Sodipodi compiles with Visual C++. If anyone would like to take on that porting challenge, we'll help try to integrate that (or other compiler project setups) so that it can be developed there as we go.
Bryce