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

[Martin Costabel]

Craig Ringer wrote:
[]
> 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.

Yes of course. I was not proposing these things as patches to be made to 
the sources. These are hacks that made things work, they are certainly 
not the best possible solutions, but they show at least the points where 
  problems existed at the moment when I made these.

> 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.

Yes, I see that this is working now, although the naming scheme is a 
little weird, and I prefer to have modules compiled not as 
-flat_namespace, but rather with -undefined dynamic_lookup. I think more 
recent versions of libtool do this automatically.
> 
> 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.

When I did this, the $LIBFREETYPE_LIBS did definitively not appear on 
this line. I admit that I did not check whether this was still necessary 
for 1.3cvs.

> 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).

This is only a cosmetic build option. I would have preferred to be able 
to use a configure parameter to get this, but it doesn't appear to be on 
offer. I want to see the what the compiler is doing during the build 
process.

> 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.

I agree there must be some other way to do this. Without this hack, 
configure detected correctly the python indicated by the configure 
option --with-pythondir=, but the code that was put in the Makefiles did 
not prevent them to look in the wrong python directories afterwards.

> 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.

Here I am not sure (haven't had the time to test) if this is still 
necessary. Without these, the libpdf and scripter plugins were not built 
with a compiler error message about an illegal reference to a symbol in 
an indirectly referenced library. It is possible that with the new build 
  system of the plugins or some other changes, this is no longer 
necessary, but one has to check these rtwo plugins whether they work, 
and the former compile error was not shifted to a runtime error. Plugin 
runtime errors are not so easy to debug, or is there a simple way to 
print the value of dlerror() at runtime without changing the sources?


> 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 .

Not on my 10.3.8 here.

> -- 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.

There is no need to do anything about this, it is too Fink-specific anyway.

> 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 have certainly not tried all possibilities, and not retried everything 
with every new version. When I have more time (but this will not happen 
for a month, and then OSX 10.4 threatens to come out - although I don't 
see major problems for scribus on it, it compiles with gcc-4.0 without 
problems; I only needed one little patch for qt-mac), I will try to help 
find more elegant and economic solutions.
  	
> 	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 ?

In Fink, there is only a static fontconfig2 library. It is somewhat 
difficult to convince the linker to use this one and not the dynamic 
fontconfig.1.dylib from /usr/X11R6/lib. If one lets the X11 
libfontconfig get linked in, it pulls in some other stuff from 
/usr/X11R6 that one probably doesn't want. The difference to other 
systems is that we don't want X11 now for this version of scribus (I 
will continue to look after the X11 version in Fink, though).

> 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 .

It is possible this is working now.

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

The QT_LIBS question needs to be addressed. I suspect that the KDE build 
system is a little sloppy there because they cannot imagine that 
somebody has two versions of libqt installed. What I saw is that 
configure detects libqt and the qt headers correctly and defines the 
variables $QT_LDFLAGS and $LIB_QT correctly and transmits them to the 
Makefiles, but they don't show up on the linker lines. This could be 
something for Makefile.am, but I don't really speak the language of the 
auto tools, so I don't know where is the right point to add something here.

-- 
Martin