It happened in r2611.
We used to have:
env.Append(CXXFLAGS = '-I$QTDIR/include/Qt3Support
-I$QTDIR/include/QtCore -I$QTDIR/include/QtGui -I$QTDIR/include/QtXml
-I$QTDIR/include/QtOpenGL -I$QTDIR/include/Qt')
Which went away and became:
if platform in ('linux','bsd'):
do some stuff
So we could add win32 to that list unless you have a deeper
understanding that things should be solved differently
Adam
2009/3/3 Adam Davison <[email protected]>:
> Also d:/qt44
>
> 2009/3/3 Nick Guenther <[email protected]>:
>> There's a line in the build script
>> print "QT path: " + flags_qtdir
>> what is that printing for you?
>>
>> On Tue, Mar 3, 2009 at 11:13 AM, Adam Davison <[email protected]> wrote:
>>> Hi,
>>>
>>> I set qtdir by running:
>>>
>>> scons.bat qtdir=d:/qt44
>>>
>>> That's where the command line is getting that from. That used to be
>>> enough. Perhaps things got disconnected somehow :)
>>>
>>> Adam
>>>
>>> 2009/3/3 Nick Guenther <[email protected]>:
>>>> qt4.py is in charge of finding Qt on Windows I think. The windows
>>>> qtdir is hardcoded to 'C:\\qt\\4.3.0' (I remember doing that now, and
>>>> thinking 'this will probably break, but I can't test it...'). Try
>>>> passing in -qtdir= to scons and see if that fixes it?
>>>>
>>>> qt4.py is smart enough to guess at where your Qt is if we pass None
>>>> for qtdir on linux; maybe the same will work on Windows?
>>>>
>>>> On Tue, Mar 3, 2009 at 10:17 AM, Adam Davison <[email protected]>
>>>> wrote:
>>>>> Sure. First compile looks like:
>>>>>
>>>>> cl /nologo /MD /TP -D__WINMIDI__ /O2 /GL /D__SNDFILE__
>>>>> "/DSETTINGS_PATH=\"Local Settings/Application Data/Mixxx/\""
>>>>> /DBPMSCHEME_FILE=\"mixxxbpmscheme.xml\" /DSETTINGS_FILE=\"mixxx.cfg\"
>>>>> /DTRACK_FILE=\"mixxxtrack.xml\" /D__WIN32__ /D__PORTAUDIO__
>>>>> /DQT3_SUPPORT /DQT3_SUPPORT_WARNINGS /DQT_THREAD_SUPPORT /DQT_SHARED
>>>>> /DQT_TABLET_SUPPORT /DWIN32 /DT_MSVC /D__LADSPA__ /D__VINYLCONTROL__
>>>>> /D__MIDISCRIPT__ /ID:\qt44\include /ID:\mixxxsvn\trunk\mixxx-winlib
>>>>> /Ilib\ladspa /Isrc\.obj /Isrc /Isrc /I. /ID:\include\atl
>>>>> /Ilib\soundtouch /Ilib\kissfft /Ilib\fidlib-0.9.9 /Ilib\ladspa
>>>>> /Ilib\xwax /Ilib\scratchlib /ID:\qt44\include\QtScript /c
>>>>> src\input.cpp /Fosrc\.obj\input.obj
>>>>>
>>>>> Adam
>>>>>
>>>>> 2009/3/3 Nick Guenther <[email protected]>:
>>>>>> On Tue, Mar 3, 2009 at 4:15 AM, Adam Davison <[email protected]>
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> At some point semi-recently someone seems to have broken the
>>>>>>> sconscript on Windows by changing the way the include paths are
>>>>>>> generated.
>>>>>>>
>>>>>>> We have things like #include <QtCore> but qt stores the files as
>>>>>>> include/QtCore/QtCore. Presumably the include path used to include all
>>>>>>> these subdirectories. Now it doesn't.
>>>>>>>
>>>>>>> A bit of random svn blaming suggests that Nick changed this code a few
>>>>>>> weeks ago...
>>>>>>>
>>>>>>> Anyone got any idea what went wrong here? I don't want to start
>>>>>>> reverting stuff really because presumably this worked for someone...
>>>>>>
>>>>>>
>>>>>> That does sound like something I'd have done, though I was careful not
>>>>>> to touch the windows sections. I do know that you must tell the
>>>>>> compiler individually about each Qt module's include dir (i.e.
>>>>>> -I.../include/QtCore -I.../include/QtGui ....). Can you show the
>>>>>> commands scons is running?
>>>>>>
>>>>>> -Nick
>>>>>>
>>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
