On 06/07/06, David Himelright <himelright.2@...1307...> wrote:
On Jul 6, 2006, at 8:08 AM, Ben Fowler wrote:
On 25/06/06, Jon A. Cruz <jon@...18...> wrote:
On Jun 25, 2006, at 12:31 AM, Ralf Stephan wrote:
Oh, another driving platform as far as I'm concerned would be OS X. ...
Jon, I'm sorry that I missed this when you originally posted in this thread, you are of course 100% correct, unfortunately so is every other comment: I don't see a single path forward that will work for everyone, ...
For Mac OS X, perhaps we ought to concentrate on
- Delivering Universal Binaries
- Creating an XCode or Project Builder project
- Native GTK+
To my mind this is roughly in order of importance to users, and so it must be noted that the first on this list likely depends on the second which ought therefore to have priority.
...
Hi Ben & Ralf, I have a little bit of experience now with the build process and Native GTK+, so I thought I'd interject with a couple of comments.
It's my experience that an XCode project isn't going to be *required* to generate universal binaries, but that bypassing the automake dependency will both create a little pain and avoid a little pain in building the application itself.
Since you can do it and I can't, I shall defer to you; but I would like to suggest that any other interested party should also refer to the Apple documentation on Universal Binaries and also on the GNU tools: http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_dev... http://developer.apple.com/unix/crossplatform.html .
My rationale for using the XCode project is that one can specify an SDK, and get a one step build of the Universal Binary. A second advantage is that it is far more friendly to occasional developers, I see it as part of our mission to support Mac users who wish to build their own applications. I appreciate that this is not cut and dried. My picture is that it involves setting up the source files and targets which duplicates information in Makefile.am, but there is not much else to it. I do have such projects, which I also find handy on those occasions when it is necessary to use gdb.
Are you really saying that it could be seen as an unfriendly act to suggest creating a directory MacOSX/ in the svn repository to contain an XCode project and supporting files?
However, I'm not aware of the number of people using OpenDarwin, which doesn't have all of the libraries present on Mac OS X.
I don't follow the reference to OpenDarwin, and I was under impression that OpenDarwin could well become less important in the future. I am not talking about libraries at the moment, but I suspect that we will have to create our own.
So before moving the Mac OS X build process to proprietary tools and libs, it's worth considering whether you'd want to leave a target in place for OpenDarwin users that allows them to build Inkscape for a darwin platform using GTK+/X11 and GNU tools.
move == copy and delete ?
No, I meant in addition. Also, isnt that a bit of a negative way of putting it. I am talking about the vendor-supported, native way of building applications, but I repeat, if you feel that my suggestions are 'unfriendly' I will assuredly drop them on the grounds that we don't wish to use, or support others who use, closed source tools.
On the first two points a 0.45 timeframe is a piece of cake. On the third, I agree with Ralf. I'm unsure how ambitious a 0.46 timeframe is for the native GTK+ libraries. The last time I built and looked at them (in April), there were pretty significant performance and reliability problems. That said, I'm really interested in working on them.
I have had a XCode project for about a year. For some reason I cannot build at all on Tiger at the moment.
I did have a Native GTK+ build of Inkscape around last November, but threw it away when we switched to svn. Since then I have had hardware problems and I am still in the process of re-creating it. I think that the GTK code has improved in reliability over the last 8 months. I am intending to continue with this, and will report any succes that I do have, but an energetic person could easily pip me to the post.
Ben.