[Scribus] Success: compile Mac/Aqua from CVS without patches

[Craig Ringer]

On Wed, 2005-03-23 at 09:42 +0100, Martin Costabel wrote:

> We could discuss them one by one, once I have found out which ones I am 
> still needing for 1.3cvs. Unfortunately, I don't have much time, so I 
> was just able to run a quick compilation; it convinced me that a few of 
> these patches are still needed, at least for me.

Here's a rough description of the status of integration for the various
bits in the .info file you posted, along with comments and questions.
I'm probably wrong about or misunderstanding a few of those that follow,
so feel free to correct me.

Remember that I can _NOT_ change configure, configure.in, the Makefile
or Makefile.in files; changes must be made to configure.in.in and the
Makefile.am files only. That means most of your changes must be adapted
somewhat to be suitable for integration.

Additionally, some of them I just don't understand, or can't see why
they're there as I have had no issues with the thing they appear to be
attempting to fix. More info about these would be great.

Anyway, comments follow. Please inform me where I'm being an idiot.

-- Patch script

Plugin `Makefile' S&R:
	Equivalent merged. The plugin makefiles were altered to use the
	-module argument  to libtool, which should cause them to be
	linked in the correct  platform specific manner. The effect
	should be much the same as the explicit addition of the flags
	you do in your Makefile script, but will work on all supported
	platforms.

Freetype `configure' S&R:

	Not merged. The explicit use of a path to a particular
	Freetype version is probably not suitable for inclusion in
	mainline CVS. I'm not sure I even understand what the
	S&R for :
		LIBS="-lfreetype
	and replacement with:
		LIBS="$LIBFREETYPE_LIBS
	is for, given that -lfreetype is never hardcoded in
	configure.in.in . Anyway, it looks like that line
	reads, in both places it appears:
		LIBS="-lfreetype "$LIBFREETYPE_LIBS" $LIBS"
	so I don't understand the point anyway.

Libtool --silent `configure' S&R:
	Not merged. Tries to remove the --silent argument
	to libtool, as far as I can tell. I don't understand
	why, and again that doesn't appear to come from
	our build files anyway (rather, it's from the KDE
	build scripts).

Python changes in `configure' and `Makefile.in':
	Not merged. I haven't looked at the Python stuff yet.
	It looks like we'll need a way to detect whether Python
	should by linked with -lpython?? or with "-framework Python"
	unless this is already provided by configure. Whatever
	changes are required must be translated so they can be made
	to configure.in.in and Makefile.am, and in a way that does
	not break anything for other platforms, so whatever eventually
	gets merged will have to be pretty different to what you
	have there.

Indirect linking changes:
	Not yet merged. I'm going to play around with that stuff
	next time I get the chance and see what's going on. An
	explanation of what that does, why it's needed, and what
	breaks if it's missing would be very helpful. Again,
	changes would have to be made to the Makefile.am, but
	in this case that's trivial.

Declarations fixes:
	Not merged. I need more info on these - what MacOS/X versions,
	gcc verisons etc they're required for, for example. I didn't
	notice any problems with any of the listed function calls
	on MacOS/X 10.3 (which is what I'm currently targeting.
	MacOS/X 10.2 will probably be obsolete by the time 1.3 is being
	stabilized for release.).

strndup:
	Not yet merged. Should probably go, since as you note only
	a strdup is required. However, strndup(...) is present on
	MacOS/X 10.3 .

-- Compile script

Environment changes:
	Those are appropriate to do as you do them currently. I don't
	see how or why most should be integrated into the build scripts.
	If you think some should (I'm not saying I think you do, but
	if you do) then please let me know why.

Configure command:
	You should be able to do away with the --with-extra-{blah} by
	setting your DYLD_LIBRARY_PATH, LIBRARY_PATH, and CPATH
	correctly. Some of the other changes you made to the makefiles
	and configure may be helped by setting PKG_CONFIG_PATH too.
	
	I'm surprised you have to use --with-qt-dir given
	that you set QTDIR - I presume this is related to the issues
	with picking up the wrong Qt at times. I haven't looked
	at this since I don't have Qt/x11 installed yet.

X11 linking:
	Equivalent merged; we now link to $(LIB_X11) instead, and the
	KDE build system sets that to "" if building against Qt/Mac.

LIBFONTCONFIG_LIBS changes:
	Not yet merged. This appears to be a fontconfig bug - fontconfig
	requires expat to link correctly, but does not include -lexpat
	in its fontconfig.la . I wanted to look into this more before
	making any build system changes, especially since fontconfig
	is linked fine on otherplatforms (ie, what's different
	about fontconfig on OS/X?). I don't understand the purpose
	of the explict -L%p/lib ; that should be handled by a
	LIBRARY_PATH env var or by 'pkg-config --libs fontconfig' .
	Maybe fink's fontconfig needs to include a -L directive in
	it's .pc file and you need to make sure that .pc file is first
	on the PKG_CONFIG_PATH ?

Addition of $(LIBFREETYPE_LIBS) to scribus/Makefile's AM_LDFLAGS:
	Not merged; This appears to be redundant, since
	$(LIBFREETYPE_LIBS) is already in Makefile.am .

I'm not sure if I missed anything. Please let me know if so.

--
Craig Ringer