On Dec 14, 2005, at 3:53 PM, Nigel Pearson wrote:


        David, some discussion on your changes:


* I'm trying to build a backend, so that's been enabled in the script.

        I suspect that most people will _not_ be building
the backend for a while, so I would like to leave that
default as is. How about a '--enable-backend' flag?


* Many of the SourceForge download addresses in there wouldn't work
  for me.  I changed the script to use a different mirror

        I guess we should have a variable up near the top
to select a particular mirror. I have added:

our $sourceforge = 'http://internap.dl.sf.net'


* FreeType is now at 2.1.10 and you can't get 2.1.9 anymore; updated

        Indeed. Will check in that change now.


* As part of one flawed attack at the problem above, I tried it with
QT 4. Its configure options are completely different. I left those
  lines in the script, commented out, in case it becomes useful to
  someone.

        Thanks. It will come in handy.

I have been building against 3.3.5 from the same mirror as the one currently in use. The big benefit in this is that 3.3.5 will build with gcc 4.0 while 3.3.4 wont. This will be useful when building for osx-x86 because you can only use gcc 4.


* After I got the QT mac version test program to compile, it wouldn't
  link.  Based on
  http://lists.trolltech.com/qt-interest/2005-05/thread00265-0.html I
  added -lobjc to the link line.  Since it seemed to have the answers
I also added '-platform macx-g++' to the configure options. I don't
  remember offhand whether that addressed a specific obstacle or if I
  just went on faith based on that article.  I know it was necessary
when I was trying to work with QT4, so it may well have been needed.

        That doesn't seem to be needed for a frontend build against
QT/Mac 3.3.4, so I have left it out for now.

* In libexif-0.6.12/libexif/exif-utils.c, line 86, exif_get_sshort is
  defined as static after being already declared without; I had to
  comment out the 'static' in order to make the compiler happy

* In qt-mac-free-3.3.4/mkspecs/macx-g++/qplatformdefs.h,

    #define QT_SOCKLEN_T int

  needs to be

    #define QT_SOCKLEN_T socklen_t

  in order to work with the latest system headers.

        Weird. The build just works for me. Are you using a newer GCC?

% gcc --v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)


* Some QT things were failing to find -lXext at link time, and after
  mucking about with fink for *way* too long trying to find it (and I
  hope I didn't mess up my configuration), I realized it was already
  installed.  So I added -L/usr/X11R6/lib to qmake_opts and QT got
  happier.

        That is not a correct fix. The OS X frontend
does not use _any_ X11 code. Nada. Ziltch.
If something is trying to pull in X11 stuff,
then _it_ needs to be fixed.

        I will do a --enable-backend build next,
and see if I can reproduce this fault.

        Is it possible that you have a Qt/X11 build
(e.g. Fink's) that is somehow being referenced?


* mythtv seems to hardcode the use of distcc into its Makefiles, and
  OSX doesn't have a distcc binary available

        Hmmm. My 10.3.9 install has it:

% which distcc
/usr/bin/distcc

        I am not sure why it is often enabled,
but configure lets you turn this off:

% ./configure --disable-distcc
# Basic Settings
Compile type     release
Compiler cache   no
DistCC           no
...

% head config.mak
# Automatically generated by configure - do not modify
PREFIX=/usr/local
QMAKE_CC=cc


(instead of the default:
 % head .osx-packager/src/myth-svn/mythtv/config.mak
 # Automatically generated by configure - do not modify
 PREFIX=/Volumes/MythOSXbuild/.osx-packager/build
 QMAKE_CC=distcc cc
)

...
@@ -1048,7 +1076,7 @@
     {
         if (! -e "$SCRIPTDIR/.osx-packager.dmg")
         {
- Syscall(['hdiutil', 'create', '-size', '1000m', "$SCRIPTDIR/.osx-packager.dmg", + Syscall(['hdiutil', 'create', '-size', '1500m', "$SCRIPTDIR/.osx-packager.dmg",

        Why increase this? The previous size is plenty big enough
for the frontend plus some extra growth (extra plugins, a few
archived copies of the frontend, et cetera). Bigger means that
people need that much extra space on their disks to actually
create the image.


Also, I have been having a problem when using the image, for some reason, the plugins get linked against an older version of libmythtv when building this way, can't seem to figure out why. The only solution I have gotten to work is removing the entire .osx-packager directory. Any Ideas?


% df -k .
Filesystem   1K-blocks   Used  Avail Capacity  Mounted on
/dev/disk1s2   1023960 807704 216256    79%    /Volumes/MythOSXbuild


--
Nigel Pearson, [EMAIL PROTECTED]|"Look at this!
Telstra Dev. Lab, Sydney, Australia  | Do you think I put this in
Office:9814 4803     Fax:  9814 4897 |  to get better reception?"
Mobile: 0408 664435  Home: 9792 6998 | Batty - Fern Gully

_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Reply via email to