I've incorporated your ideas in config-v6.. On Tue, 1 Mar 2005, Nigel Pearson wrote: ]> I've also incorporated all the using_XXX config options in ]> settings.pro, except for using_dvb. Since there is no standard ]> directory for the dvb headers yet it can't be autodetected. ] Sure, but wouldn't it be better to have it enabled or ]disabled in the same place? (e.g. configure --enable-dvb)
Yep, now you can do it on the command line, mine is ./configure --enable-dvb --dvb-path=/cvs/myth/dvb-kernel/linux/include --disable-firewire --enable-xvmc ]1) On Mac OS X, there are some problems with ] duplication of compile optimisation flags: Try it now. Duplication isn't harmful to the compiler, but it makes it harder to understand what options are actually being used. ]I just checked in a slight settings.pro change for the Mac. ]You can now change this part of your patch from: ]+ QMAKE_CXXFLAGS_RELEASE = $$OPTFLAGS done ]2) Note that -altivec is now included twice. Need to ] remove the Altivec support block from settings.pro I've removed it, but I also had to add debug { # make sure we still get altivec support contains( TARGET_ARCH_POWERPC, yes ) { QMAKE_CXXFLAGS_RELEASE = $$OPTFLAGS -O2 -g } } So that the altivec settings get picked up in debug as well. ]3) How do you feel about adding '--enable-fast'? ] (both Solaris CC and Apple GCC support --fast) This is a question for Issac. ]4) The tune settings don't seem to find their way anywhere: Oops! fixed now ]+ test -a /proc/cpuinfo typo, fixed ]* Similarly, line 739 and 764, the == should be = oi, I obviously spend too much time in C. ]* Line 1338 and 1353, the -e should be -f ]Of course, there are lots of other fixes I need to commit to ]get Solaris building to work, but while we are re-engineering ]configure, it may be the right time to do it? -f works fine in all these cases so I'm using that now. >From your other message: ]1) The CFLAGS, which may have been customised for Darwin or ] with --tune, are overwritten with $PCFLAGS on line 777 Thanks, this let me fix this quickly. ]2) Quite a few lines in settings.pro are like: ]using_firewire { ] DEFINES += USING_FIREWIRE ] It would probably be safe for configure to set defines ]for any using_ variable. Some of them do not currently ]have corresponding -DUSING_ values (e.g. using_lirc), ]but extra defines should not matter? Ok, I've moved most of the defines to the configure script. This considerably shrinks the settings.pro file I'm not setting any extra USING_ defines for now. I think it's a good idea, just so someone doesn't begin using one of these defines, thinking it will work, and then ending up debugging the configure script. But the arguement against it is that it is just chaff on the compiler command line, I'd like to hear what other developers think. -- Daniel
config-v6.patch.bz2
Description: Binary data
_______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev