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.

I'm attempting a build now as I'm writing this, so the answer may already be a moot point.

There isn't much that won't work assuming you have Gtk. I presume that Gtk+ has been ported to MacOSX, so it should (theoretically) just compile. If you are feeling up to it, send a patch of changes to make it work on MacOSX.

njh

On Fri, 7 Nov 2003, T Ingham wrote:

To get autogen to run I had to perform the following ( Assuming users have fink installed )

sudo fink install gtk+ ( which installs gtk+ and gtk+2 )

setenv ACLOCAL_FLAGS "-I /sw/share/aclocal" (That's an i, not L )

Currently I'm stuck on: checking for png_read_info in -lpng... no configure: error: Libpng is needed to compile inkscape

Where libpng12 is located within /sw/lib

Any ideas on getting past this?

Yes. We've set up a wiki page for folks to share problems and solutions in compiling Inkscape.

http://www.inkscape.org/cgi-bin/wiki.pl?CompilingInkscape

Short answer is that you need the devel lib's for libpng, because they have the headers and stuff for compiling programs that use libpng.

Also, please post your findings about compiling on OSX there, so other OSX users can share stuff learned. It also helps the developers figure out how to do things better and will help identify stuff to add to the install docs.

Bryce

-thomas

On Nov 6, 2003, at 4:53 PM, Nathan Hurst wrote:

...

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.

I'm attempting a build now as I'm writing this, so the answer may already be a moot point.

There isn't much that won't work assuming you have Gtk. I presume that Gtk+ has been ported to MacOSX, so it should (theoretically) just compile. If you are feeling up to it, send a patch of changes to make it work on MacOSX.

njh

---

This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Nov 7, 2003, at 4:50 PM, Daniel Díaz wrote:

Hello, Thomas et al.

On Fri, 2003-11-07 at 11:47, T Ingham wrote:

...

To get autogen to run I had to perform the following ( Assuming users have fink installed )

sudo fink install gtk+ ( which installs gtk+ and gtk+2 )

I have problems with this.

I have fink installed but the `fink install gtk+' command will only install GTK+ 1.2. `fink install gtk+2' yells that "E: Package gtk+2 has no installation candidate."

Later on, while ./configuring Inkscape, it throws the following:

configure: error: Library requirements (gtk+-2.0 >= 2.0.0 libart-2.0

...

=

2.3.10 libxml-2.0 >= 2-2.4.24) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.

I installed a gtk2.dmg a while ago, but I can't remember what happened to this.

I'm not really a fan of MacOS X, but if I can help to test this one out, just tell me.

Any help with the GTK+2 thing would be appreciated.

I did just install gtk+ and it installed everything in the gtk base. I'm thinking that perhaps your source list in fink is not up-to-date, or perhaps your fink is old?

-t

On Fri, 7 Nov 2003, T Ingham wrote:

Further with libpng, I have also downloaded the source from sf.net and compiled / installed. I still run into the same problem during configure.

I can't help but wonder perhaps if I've borked my system somewhere along the line. I can't seem to find libpng-devel anywhere ( for OSX )

-t

Try searching on 'libpng3-devel', maybe?

It would be extremely strange if OSX didn't have this library in some form or other.

Here are the specific files that my 'libpng3-devel' installs, for what it's worth:

{brimstone} ~ (9): rpm -q libpng3-devel --filesbypkg libpng3-devel /usr/include/libpng libpng3-devel /usr/include/libpng12 libpng3-devel /usr/include/libpng12/png.h libpng3-devel /usr/include/libpng12/pngconf.h libpng3-devel /usr/include/png.h libpng3-devel /usr/include/pngconf.h libpng3-devel /usr/lib/libpng.so libpng3-devel /usr/lib/libpng12.so libpng3-devel /usr/share/doc/libpng3-devel-1.2.4 libpng3-devel /usr/share/doc/libpng3-devel-1.2.4/CHANGES libpng3-devel /usr/share/doc/libpng3-devel-1.2.4/README libpng3-devel /usr/share/doc/libpng3-devel-1.2.4/TODO libpng3-devel /usr/share/doc/libpng3-devel-1.2.4/example.c libpng3-devel /usr/share/doc/libpng3-devel-1.2.4/libpng.txt libpng3-devel /usr/share/man/man3/libpng.3.bz2 libpng3-devel /usr/share/man/man3/libpngpf.3.bz2

The .h's and .so's are probably where the money is here.

Bryce

You can try overriding the configure check by editing 'configure', searching for the lines relating to libpng, and commenting stuff out to skip the test. That'll force it to try compiling regardless of whether it detects libpng and will definitively test whether it's the autoconf stuff that's in error, or if something is legitimately missing from where it needs to be.

Bryce

On Fri, 7 Nov 2003, T Ingham wrote:

I plan on posting this stuff to the wiki once it's figured out, hopefully it's okay that I'm using the mail list to figure this stuff out.

the really strange thing is this:

[6:15pm tingham /sw/include]|% ls libpng* libpng: libpng png.h pngconf.h

libpng12: libpng png.h pngconf.h

//-----------------------------------------//

[6:17pm tingham /sw/lib]|% ls libpng* libpng.2.1.0.12.dylib libpng.3.1.2.5.dylib libpng.a libpng12.0.1.2.5.dylib libpng12.a libpng.2.dylib libpng.3.dylib libpng.dylib libpng12.0.dylib libpng12.dylib

//----------------------------------------//

[6:17pm tingham /sw/bin]|% ls libpng* libpng-config libpng12-config

//-----------------------------------------//

[6:18pm tingham /sw/share/man]|% ls -lR ./* | grep png -rw-r--r-- 1 root wheel 433 6 Nov 22:26 pngtopnm.1 -rw-r--r-- 1 root wheel 433 6 Nov 22:26 pnmtopng.1 -rw-r--r-- 1 root admin 160934 2 Nov 11:31 libpng.3 -rw-r--r-- 1 root admin 17107 2 Nov 11:31 libpngpf.3 -rw-r--r-- 1 root admin 1858 2 Nov 11:31 png.5

So I'm guessing it's just a matter of telling the configure script where to find libpng.. as there is some stuff installed in /usr/local ( but I have no idea how it got there )

-Thomas

---

This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

After much head-scratching and bargain-basementing I have gotten past the configure phase with InkScape.

Once I ran make, I ran into errors dealing with malloc.h includes. Replacing these instances with unistd.h allowed make to continue. The files affected were:

src/helper/action.c src/xml/repr-io.c libarikkei/arikkei-token.c

I am now confronted with a different problem, which completely befuddles me ( which isn't difficult ) perhaps someone here can assist me.

I have posted the necessary changes to my system for basic configuration to the wiki, for the benefit of all. ( And updated a fink FAQ in the process :)

Current Stopping point:

gcc -DHAVE_CONFIG_H -I. -I. -I.. -DPACKAGE_LOCALE_DIR="/usr/local/share/locale" -DINKSCAPE_PIXMAPDIR="/usr/local/share/inkscape" -DDATADIR="/usr/local/share" -I. -I./xml -I./svg -I/sw/include/gtk-2.0 -I/sw/lib/gtk-2.0/include -I/sw/include/atk-1.0 -I/sw/include/pango-1.0 -I/usr/X11R6/include -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -I/sw/include/libart-2.0 -I/sw/include/libxml2 -I/sw/include -DINKSCAPE_VERSION="0.0" -I/sw/include -I/sw/include -c uri-references.c -MT uri-references.lo -MD -MP -MF .deps/uri-references.TPlo -o uri-references.o >/dev/null 2>&1 /bin/sh ../libtool --mode=link gcc -I/sw/include -L/sw/lib -o libinkscape.la attributes.lo sp-object.lo sp-object-repr.lo sp-object-group.lo sp-defs.lo sp-item.lo sp-item-group.lo sp-symbol.lo sp-marker.lo sp-use.lo sp-anchor.lo sp-root.lo sp-image.lo sp-path.lo sp-shape.lo sp-rect.lo sp-ellipse.lo sp-star.lo sp-spiral.lo sp-line.lo sp-polyline.lo sp-polygon.lo sp-chars.lo sp-text.lo sp-paint-server.lo sp-gradient.lo sp-pattern.lo sp-clippath.lo sp-mask.lo sp-animation.lo color.lo style.lo document.lo document-undo.lo uri-references.lo ar cru .libs/libinkscape.a .libs/attributes.o .libs/sp-object.o .libs/sp-object-repr.o .libs/sp-object-group.o .libs/sp-defs.o .libs/sp-item.o .libs/sp-item-group.o .libs/sp-symbol.o .libs/sp-marker.o .libs/sp-use.o .libs/sp-anchor.o .libs/sp-root.o .libs/sp-image.o .libs/sp-path.o .libs/sp-shape.o .libs/sp-rect.o .libs/sp-ellipse.o .libs/sp-star.o .libs/sp-spiral.o .libs/sp-line.o .libs/sp-polyline.o .libs/sp-polygon.o .libs/sp-chars.o .libs/sp-text.o .libs/sp-paint-server.o .libs/sp-gradient.o .libs/sp-pattern.o .libs/sp-clippath.o .libs/sp-mask.o .libs/sp-animation.o .libs/color.o .libs/style.o .libs/document.o .libs/document-undo.o .libs/uri-references.o~ranlib .libs/libinkscape.a ar: .libs/uri-references.o~ranlib: No such file or directory make[3]: *** [libinkscape.la] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

There is a file .libs/uri-references.o ( and .lo )

Thanks,

-thomas

T Ingham wrote:

The previous issue was related to Apple's version of glibtoolize, replacing with fink's copy fixes the ranlib issue.

Now however, I have a more interesting note. I got the damn thing compiled!

Cool! Can you post a patch when you've worked out all the issues? I would consider not working on MacOSX a bug.

Here are some images showing a very unhappy Inkscape:

http://www.coalmarch.com/images/inkscape/inkscape_osx_01.png http://www.coalmarch.com/images/inkscape/inkscape_osx_02.png http://www.coalmarch.com/images/inkscape/inkscape_osx_03.png

You can see that some of the icons appear to be loading in a corrupted fashion. This could be related to my cvs checkout ( done anon ) or perhaps the files needed for these icons simply aren't present. I can't say for sure.

Nah, this happens for me too. You just need to install inkscape.

njh

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