waf - Project Hosting on Google Code

Yesterday 40 hours ago issue 567 (The ctypes based ansiterm code fails when running Waf from w...) reported by jamie.alan.kirpatrick - >> operating system: Win32 >> python version: 2.6.4 >> waf version (or svn revision): 1.5.10 >> observed output and expected output: No output. >> how to reproduce the problem? Create an MSBuild xml file and define a target that calls out to Waf using the <Exec/> command tag. To solve the problem I have had to hack Waf so that it throws an exception in the ctypes related section. This forces it to fail back on the other implementation which works fine. I have tried to find out if there is a generic way to detect when running under MSBuild so that some reasonable solution can be found to this issue - see my question here: http://stackoverflow.com/questions/1818437/is-there-a-way-for-a-program-to-detect-if- it-was-called-by-msbuild-or-not. Not sure what to do about this. >> operating system: Win32 >> python version: 2.6.4 >> waf version (or svn revision): 1.5.10 >> observed output and expected output: No output. >> how to reproduce the problem? Create an MSBuild xml file and define a target that calls out to Waf using the <Exec/> command tag. To solve the problem I have had to hack Waf so that it throws an exception in the ctypes related section. This forces it to fail back on the other implementation which works fine. I have tried to find out if there is a generic way to detect when running under MSBuild so that some reasonable solution can be found to this issue - see my question here: http://stackoverflow.com/questions/1818437/is-there-a-way-for-a-program-to-detect-if- it-was-called-by-msbuild-or-not. Not sure what to do about this. Last 7 days Nov 25, 2009 issue 565 (Add support for xlc on AIX) commented on by michael....@informatik.uni-hamburg.de - The following patches add support for both xlc and xlc++ on AIX. (The xlc one fixes some smaller bugs present in the previous patch.) The following patches add support for both xlc and xlc++ on AIX. (The xlc one fixes some smaller bugs present in the previous patch.) Last 30 days Nov 24, 2009 issue 566 (qmake from qt3 doesn't support -query QT_VERSION) Status changed by tnagy1024 - Qt3 should really disappear. If you want that, use waf 1.3 - waf 1.4 Status: NoSeriously Qt3 should really disappear. If you want that, use waf 1.3 - waf 1.4 Status: NoSeriously Nov 24, 2009 issue 566 (qmake from qt3 doesn't support -query QT_VERSION) reported by suokkos - >> operating system: Ubuntu 9,10 >> python version: 2.6.4 >> waf version (or svn revision): 1.5.8 >> observed output and expected output: Qt4 detection throws unhandled exception if system has qmake from qt3. snip File "/usr/share/waf/wafadmin/Tools/qt4.py", line 507, in detect detect_qt4(conf) File "/usr/share/waf/wafadmin/Tools/qt4.py", line 359, in detect_qt4 version = Utils.cmd_output([qmake, '-query', 'QT_VERSION']).strip() File "/usr/share/waf/wafadmin/Utils.py", line 416, in cmd_output raise ValueError(msg) ValueError: command execution failed: ['/usr/bin/qmake', '-query', 'QT_VERSION'] -> 'Unknown\n' Command-line output from different qmake versions. $ qmake-qt4 -query QT_VERSION 4.5.2 $ qmake -query QT_VERSION Unknown $ qmake-qt4 -version QMake version 2.01a Using Qt version 4.5.2 in /usr/lib $ qmake -version Qmake version: 1.07a (Qt 3.3.8b) Qmake is free software from Trolltech ASA. >> how to reproduce the problem? Configure the qt demo from waf sources >> Solution: Handle the exception thrown from command execution in qt4.py:359 qmake version selection code. >> operating system: Ubuntu 9,10 >> python version: 2.6.4 >> waf version (or svn revision): 1.5.8 >> observed output and expected output: Qt4 detection throws unhandled exception if system has qmake from qt3. snip File "/usr/share/waf/wafadmin/Tools/qt4.py", line 507, in detect detect_qt4(conf) File "/usr/share/waf/wafadmin/Tools/qt4.py", line 359, in detect_qt4 version = Utils.cmd_output([qmake, '-query', 'QT_VERSION']).strip() File "/usr/share/waf/wafadmin/Utils.py", line 416, in cmd_output raise ValueError(msg) ValueError: command execution failed: ['/usr/bin/qmake', '-query', 'QT_VERSION'] -> 'Unknown\n' Command-line output from different qmake versions. $ qmake-qt4 -query QT_VERSION 4.5.2 $ qmake -query QT_VERSION Unknown $ qmake-qt4 -version QMake version 2.01a Using Qt version 4.5.2 in /usr/lib $ qmake -version Qmake version: 1.07a (Qt 3.3.8b) Qmake is free software from Trolltech ASA. >> how to reproduce the problem? Configure the qt demo from waf sources >> Solution: Handle the exception thrown from command execution in qt4.py:359 qmake version selection code. Nov 23, 2009 issue 565 (Add support for xlc on AIX) commented on by michael....@informatik.uni-hamburg.de - We do not use xlc++ at the moment, therefore I did not add support for it. I guess I will take a look at it in the next few days. We do not use xlc++ at the moment, therefore I did not add support for it. I guess I will take a look at it in the next few days. Nov 20, 2009 issue 565 (Add support for xlc on AIX) commented on by bohan.go...@retropaganda.info - what about support for xlc++ in compiler_cxx.py ? what about support for xlc++ in compiler_cxx.py ? Nov 20, 2009 issue 565 (Add support for xlc on AIX) reported by michael....@informatik.uni-hamburg.de - The following patch adds support for xlc on AIX and sets it as the preferred compiler. The following patch adds support for xlc on AIX and sets it as the preferred compiler. Nov 17, 2009 issue 511 (Add a way to read variables from pkg-config to check_cfg) commented on by sur...@ikkoku.de - I created a patch to support this kind of functionality. It is working pretty well for me. This makes it possible to do something like this: conf.check_cfg(package='dbus-1', variables='system_bus_default_address session_bus_services_dir') This currently sets: 'DBUS-1_session_bus_services_dir' ['/usr/share/dbus-1/services'] 'DBUS-1_system_bus_default_address' ['unix:path=/var/run/dbus/system_bus_socket'] I created a patch to support this kind of functionality. It is working pretty well for me. This makes it possible to do something like this: conf.check_cfg(package='dbus-1', variables='system_bus_default_address session_bus_services_dir') This currently sets: 'DBUS-1_session_bus_services_dir' ['/usr/share/dbus-1/services'] 'DBUS-1_system_bus_default_address' ['unix:path=/var/run/dbus/system_bus_socket'] Nov 14, 2009 waf-1.5.10.tar.bz2 (source, book and demos) file uploaded by tnagy1024 - Labels: Type-Archive OpSys-All Featured Labels: Type-Archive OpSys-All Featured Nov 14, 2009 waf-1.5.10 (waf 1.5.10 binary (run from a writeable folder)) file uploaded by tnagy1024 - Labels: Type-Executable OpSys-All Featured Labels: Type-Executable OpSys-All Featured Nov 14, 2009 r6824 (New release. ) committed by tnagy1024 - New release. New release. Nov 14, 2009 r6823 (New release ) committed by tnagy1024 - New release New release Nov 14, 2009 r6822 (docs) committed by tnagy1024 - docs docs Nov 14, 2009 r6821 (docs) committed by tnagy1024 - docs docs Nov 14, 2009 r6820 (docs) committed by tnagy1024 - docs docs Nov 14, 2009 r6819 (python 2.3) committed by tnagy1024 - python 2.3 python 2.3 Nov 14, 2009 r6818 (python 2.3 has no format_exc()) committed by tnagy1024 - python 2.3 has no format_exc() python 2.3 has no format_exc() Nov 14, 2009 r6817 (docs) committed by tnagy1024 - docs docs Nov 14, 2009 r6816 (stupid py3k) committed by tnagy1024 - stupid py3k stupid py3k Nov 14, 2009 r6815 (docs) committed by tnagy1024 - docs docs Nov 14, 2009 r6814 (better error message) committed by tnagy1024 - better error message better error message Nov 14, 2009 r6813 (stupid py3k) committed by tnagy1024 - stupid py3k stupid py3k Nov 14, 2009 r6812 (stupid py3k) committed by tnagy1024 - stupid py3k stupid py3k Nov 14, 2009 r6811 (stupid py3k) committed by tnagy1024 - stupid py3k stupid py3k Nov 14, 2009 r6810 (stupid py3k) committed by tnagy1024 - stupid py3k stupid py3k Nov 14, 2009 r6809 (stupid py3k) committed by tnagy1024 - stupid py3k stupid py3k Nov 14, 2009 r6808 (py3k) committed by tnagy1024 - py3k py3k Nov 14, 2009 r6807 (stupid py3k) committed by tnagy1024 - stupid py3k stupid py3k Nov 14, 2009 r6806 (stupid py3k) committed by tnagy1024 - stupid py3k stupid py3k Nov 14, 2009 r6805 (stupid py3k) committed by tnagy1024 - stupid py3k stupid py3k Nov 14, 2009 r6804 (stupid py3k) committed by tnagy1024 - stupid py3k stupid py3k Nov 14, 2009 r6803 (stupid py3k) committed by tnagy1024 - stupid py3k stupid py3k Nov 14, 2009 r6802 (python 3 is a joke) committed by tnagy1024 - python 3 is a joke python 3 is a joke Nov 14, 2009 r6801 (py3k) committed by tnagy1024 - py3k py3k Nov 14, 2009 r6800 (leftover) committed by tnagy1024 - leftover leftover Nov 14, 2009 r6799 (make certain it compiles) committed by tnagy1024 - make certain it compiles make certain it compiles Nov 14, 2009 issue 564 (cxx demo fails to compile) Status changed by tnagy1024 - Status: WontFix Status: WontFix Nov 14, 2009 issue 564 (cxx demo fails to compile) commented on by omnigoat - Aha. I took a look with -v, and noticed a flag IMPLIB was relative as opposed to /OUT's absolute (not actually a problem!). I MSDNed IMPLIB (http://msdn.microsoft.com/en-us/library/67wc07b9%28VS.80%29.aspx), and noticed that in the source files for the demo, there are no functions marked for export, and neither is the export command-line argument (/EXPORT) defined. LINK.exe is simply not generating the .lib files because it has decided it doesn't need to, effectively. I tested by modifying b2.cpp to include this line underneath the static integer: __declspec(dllexport) void do_nothing() {} And then rebuilt. This caused teshshlib.lib to be generated. shlib-1.lib, which does not use b2.cpp, remained absent. I then added this line to the bottom of d1.cpp : __declspec(dllexport) void do_nothing_twice() {} Both .lib files were generated, and compilation continued! However, line 49 in the wscript (demos/cxx/wscript) has 'uselib = MYPROG'. I'm unsure as to the intention of this, but it causes a problem: [31/44] cxx_link: build\debug\src\e1_5.o -> build\debug\src\program_dyn_linked.e xe 21:42:50 runner[33/44] system command -> ['C:\\Program Files\\Microsoft Visual Studio 8\\VC\\BIN\\LINK.exe', 'debug\\src\\e1_5.o', '/OUT:C:\\mywaf\\demos\\cxx\ \build\\debug\\src\\program_dyn_linked.exe', '/NOLOGO', '/MANIFEST', '/LIBPATH:d ebug\\src', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\ATLMFC\\ LIB', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\LIB', '/LIBPAT H:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\lib', '/LIBPATH :C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\lib', 'libteststaticli b.lib', 'shlib1.lib', 'testshlib.lib', 'm.lib'] cxx_link: build\default\src\e1_5.o -> build\default\src\program_dyn_linked.exe 21:42:50 runner system command -> ['C:\\Program Files\\Microsoft Visual Studio 8 \\VC\\BIN\\LINK.exe', 'default\\src\\e1_5.o', '/OUT:C:\\mywaf\\demos\\cxx\\build \\default\\src\\program_dyn_linked.exe', '/NOLOGO', '/MANIFEST', '/LIBPATH:defau lt\\src', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\ATLMFC\\LI B', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\LIB', '/LIBPATH: C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\lib', '/LIBPATH:C :\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\lib', 'libteststaticlib. lib', 'shlib1.lib', 'testshlib.lib', 'm.lib'] There's a rogue m.lib in there. It's never specified to be generated, and it's certainly not a system library. The removal of line 49 from the wscript results in a successful compilation of all the cxx demo. Looks like the demo needs to be cleaned up a little for Windows - I'm guessing the tools on linux cope with everything listed here fine. Ah well. Hope that helps. Aha. I took a look with -v, and noticed a flag IMPLIB was relative as opposed to /OUT's absolute (not actually a problem!). I MSDNed IMPLIB (http://msdn.microsoft.com/en-us/library/67wc07b9%28VS.80%29.aspx), and noticed that in the source files for the demo, there are no functions marked for export, and neither is the export command-line argument (/EXPORT) defined. LINK.exe is simply not generating the .lib files because it has decided it doesn't need to, effectively. I tested by modifying b2.cpp to include this line underneath the static integer: __declspec(dllexport) void do_nothing() {} And then rebuilt. This caused teshshlib.lib to be generated. shlib-1.lib, which does not use b2.cpp, remained absent. I then added this line to the bottom of d1.cpp : __declspec(dllexport) void do_nothing_twice() {} Both .lib files were generated, and compilation continued! However, line 49 in the wscript (demos/cxx/wscript) has 'uselib = MYPROG'. I'm unsure as to the intention of this, but it causes a problem: [31/44] cxx_link: build\debug\src\e1_5.o -> build\debug\src\program_dyn_linked.e xe 21:42:50 runner[33/44] system command -> ['C:\\Program Files\\Microsoft Visual Studio 8\\VC\\BIN\\LINK.exe', 'debug\\src\\e1_5.o', '/OUT:C:\\mywaf\\demos\\cxx\ \build\\debug\\src\\program_dyn_linked.exe', '/NOLOGO', '/MANIFEST', '/LIBPATH:d ebug\\src', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\ATLMFC\\ LIB', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\LIB', '/LIBPAT H:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\lib', '/LIBPATH :C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\lib', 'libteststaticli b.lib', 'shlib1.lib', 'testshlib.lib', 'm.lib'] cxx_link: build\default\src\e1_5.o -> build\default\src\program_dyn_linked.exe 21:42:50 runner system command -> ['C:\\Program Files\\Microsoft Visual Studio 8 \\VC\\BIN\\LINK.exe', 'default\\src\\e1_5.o', '/OUT:C:\\mywaf\\demos\\cxx\\build \\default\\src\\program_dyn_linked.exe', '/NOLOGO', '/MANIFEST', '/LIBPATH:defau lt\\src', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\ATLMFC\\LI B', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\LIB', '/LIBPATH: C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\lib', '/LIBPATH:C :\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\lib', 'libteststaticlib. lib', 'shlib1.lib', 'testshlib.lib', 'm.lib'] There's a rogue m.lib in there. It's never specified to be generated, and it's certainly not a system library. The removal of line 49 from the wscript results in a successful compilation of all the cxx demo. Looks like the demo needs to be cleaned up a little for Windows - I'm guessing the tools on linux cope with everything listed here fine. Ah well. Hope that helps. Nov 13, 2009 issue 564 (cxx demo fails to compile) Status changed by tnagy1024 - Then look at the linker commands and at the linker parameters (waf -v) Status: Assigned Then look at the linker commands and at the linker parameters (waf -v) Status: Assigned Nov 13, 2009 issue 564 (cxx demo fails to compile) commented on by omnigoat - Ah, sorry, I assumed things were okay because it said 'ok'. However... This hasn't worked for ages (read: months), and the MSVC2008/Windows 7 SDK are new as of monday, I just didn't file a ticket for a looong time. I'm at home now (not work), so here is the configuration for a completely different system (different machine), running Windows XP (32-bit), with python 2.5.2, with only the Microsoft Visual Studio 2005 Compiler Tools installed, with no weird SDKs or anything else. You can achieve this system setup by clean-installing Windows XP SP2 and installing MSVC2005 Professional Edition. Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\x86_amd64\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\amd64\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe Checking for program LINK : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\LINK.exe Checking for program LIB : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\LIB.exe Checking for program MT : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\MT.exe Checking for program RC : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\RC.exe Checking for msvc : ok sub-configuration file called (demo) 'configure' finished successfully (8.125s) The problems when building are identical. No corresponding .lib files for the shared libraries are generated. I hope that helps. Soz for providing a misleading configuration output. Ah, sorry, I assumed things were okay because it said 'ok'. However... This hasn't worked for ages (read: months), and the MSVC2008/Windows 7 SDK are new as of monday, I just didn't file a ticket for a looong time. I'm at home now (not work), so here is the configuration for a completely different system (different machine), running Windows XP (32-bit), with python 2.5.2, with only the Microsoft Visual Studio 2005 Compiler Tools installed, with no weird SDKs or anything else. You can achieve this system setup by clean-installing Windows XP SP2 and installing MSVC2005 Professional Edition. Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\x86_amd64\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\amd64\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe Checking for program LINK : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\LINK.exe Checking for program LIB : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\LIB.exe Checking for program MT : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\MT.exe Checking for program RC : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\RC.exe Checking for msvc : ok sub-configuration file called (demo) 'configure' finished successfully (8.125s) The problems when building are identical. No corresponding .lib files for the shared libraries are generated. I hope that helps. Soz for providing a misleading configuration output. Nov 13, 2009 r6798 (docs) committed by tnagy1024 - docs docs Nov 13, 2009 r6797 (another example) committed by tnagy1024 - another example another example Nov 13, 2009 r6796 (new release in preparation) committed by tnagy1024 - new release in preparation new release in preparation Nov 13, 2009 r6795 (new release in preparation) committed by tnagy1024 - new release in preparation new release in preparation Nov 13, 2009 issue 564 (cxx demo fails to compile) Status changed by tnagy1024 - Just look at the visual studio error message: Error: The system was unable to find the specified registry key or value You are also using a new compiler on a new environment (Windows 7) so you'll have to investigate wether it is a problem with your system (which i suspect) or a change in the compiler system (less likely, Microsoft apps behaving usually well regarding backward compatibility). Status: NoSeriously Just look at the visual studio error message: Error: The system was unable to find the specified registry key or value You are also using a new compiler on a new environment (Windows 7) so you'll have to investigate wether it is a problem with your system (which i suspect) or a change in the compiler system (less likely, Microsoft apps behaving usually well regarding backward compatibility). Status: NoSeriously Nov 12, 2009 issue 564 (cxx demo fails to compile) reported by omnigoat - >> operating system: Windows XP 32-bit >> python version: python 2.5.1 >> waf version (or svn revision): r6794 >> observed output and expected output: observed: configure succeeded. build correctly builds up to item 25. after the display of item 25, prints: "Build failed -> missing file: 'C:\\....\\demos\\cxx\\build\\default\\src\\testshlib.lib' -> missing file: 'C:\\....\\demos\\cxx\\build\\default\\src\\shlib1.lib'" Further investigation reveals the files testshlib.lib and shlib1-1.lib do not exist in \\build\\default\\src\\ expected testshlib.lib and shlib1-1.lib to have been generated by items 24 and 25: "[24/44] cxx_link: build\default\src\a1_2.o build\default\src\b1_2.o build\default\src\b2_2.o -> build\default\src\testshlib.dll build\default\src\testshlib.lib [25/44] cxx_link: build\default\src\d1_4.o -> build\default\src\shlib1-1.dll build\default\src\shlib1.lib" >> how to reproduce the problem? My waf directory is a clean read-only checkout on a Windows XP 32-bit system, using both the Visual Studio 8.0 and the Visual Studio 9.0 (2008) Compiler Suite, with the Windows 7 SDK. Included is the configuration: waf configure Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\x86_amd64\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\amd64\CL.exe Error: The system was unable to find the specified registry key or value Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\x86_amd64\CL.exe Error: The system was unable to find the specified registry key or value Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\CL.exe Error: The system was unable to find the specified registry key or value Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\x86_IA64\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\x86_amd64\CL.exe Checking for program LINK : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\x86_amd64\LINK.exe Checking for program LIB : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\x86_amd64\LIB.exe Checking for program MT : ok C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\MT.exe Checking for program RC : ok C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\RC.exe Checking for msvc : ok sub-configuration file called (demo) 'configure' finished successfully (2.984s) This is simply building the cxx demo. I called waf configure then waf build as per standard. >> operating system: Windows XP 32-bit >> python version: python 2.5.1 >> waf version (or svn revision): r6794 >> observed output and expected output: observed: configure succeeded. build correctly builds up to item 25. after the display of item 25, prints: "Build failed -> missing file: 'C:\\....\\demos\\cxx\\build\\default\\src\\testshlib.lib' -> missing file: 'C:\\....\\demos\\cxx\\build\\default\\src\\shlib1.lib'" Further investigation reveals the files testshlib.lib and shlib1-1.lib do not exist in \\build\\default\\src\\ expected testshlib.lib and shlib1-1.lib to have been generated by items 24 and 25: "[24/44] cxx_link: build\default\src\a1_2.o build\default\src\b1_2.o build\default\src\b2_2.o -> build\default\src\testshlib.dll build\default\src\testshlib.lib [25/44] cxx_link: build\default\src\d1_4.o -> build\default\src\shlib1-1.dll build\default\src\shlib1.lib" >> how to reproduce the problem? My waf directory is a clean read-only checkout on a Windows XP 32-bit system, using both the Visual Studio 8.0 and the Visual Studio 9.0 (2008) Compiler Suite, with the Windows 7 SDK. Included is the configuration: waf configure Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\x86_amd64\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 8\VC\BIN\amd64\CL.exe Error: The system was unable to find the specified registry key or value Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\x86_amd64\CL.exe Error: The system was unable to find the specified registry key or value Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\CL.exe Error: The system was unable to find the specified registry key or value Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\x86_IA64\CL.exe Checking for program CL : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\x86_amd64\CL.exe Checking for program LINK : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\x86_amd64\LINK.exe Checking for program LIB : ok C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\x86_amd64\LIB.exe Checking for program MT : ok C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\MT.exe Checking for program RC : ok C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\RC.exe Checking for msvc : ok sub-configuration file called (demo) 'configure' finished successfully (2.984s) This is simply building the cxx demo. I called waf configure then waf build as per standard. Nov 12, 2009 issue 563 (RFC: Permit to set the default build environment to avoid en...) commented on by julien.charbon - First, thank for your quick and detailed replies: - My main goal is not to push for the patch acceptance but for clean Waf usage/understanding. - And yes because I'm porting a build project from Makefile to Waf I still have Makefile bad habits. I'm already using 'uselib_local' that fit perfectly my task dependency needs when I can use it. [Simple library]. But when the library need to be compiled with ./configure && make && make all, it's much harder to use classical Waf tasks dependencies... add_group() was the easy path for my need. I will remove add_group() task dependencies Thank again for your time, you can close that bug and forgot about the patch. First, thank for your quick and detailed replies: - My main goal is not to push for the patch acceptance but for clean Waf usage/understanding. - And yes because I'm porting a build project from Makefile to Waf I still have Makefile bad habits. I'm already using 'uselib_local' that fit perfectly my task dependency needs when I can use it. [Simple library]. But when the library need to be compiled with ./configure && make && make all, it's much harder to use classical Waf tasks dependencies... add_group() was the easy path for my need. I will remove add_group() task dependencies Thank again for your time, you can close that bug and forgot about the patch. Nov 12, 2009 issue 563 (RFC: Permit to set the default build environment to avoid en...) commented on by tnagy1024 - First of all, that setenv call may be bound to a method in your scripts (no need to modify Waf for that): @feature('') @before('init_cxx') def set_my_env(self): print ("setting another environment") self.env = bld.env_of_name(getattr(self, 'envname', 'default')) bld.new_task_gen(envname='debug') But i do know that a little while after someone will want to disable some instance just to build several variants/only one variant at a time. The above is an antipattern, which is a consequence of Makefile practice. Making easier to do that is against the best practices, and the change will not be made. --- The add_group() feature has a very particular usecase ("building a compiler before using it") which is not really for handling simple dependencies, and which breaks parallelism (slow compilations). Judging by the folder names you wrote, I not only think that those groups are unnecessary, but I also suspect uselib_local was not used. A workaround is to create the clones after each new group though. First of all, that setenv call may be bound to a method in your scripts (no need to modify Waf for that): @feature('') @before('init_cxx') def set_my_env(self): print ("setting another environment") self.env = bld.env_of_name(getattr(self, 'envname', 'default')) bld.new_task_gen(envname='debug') But i do know that a little while after someone will want to disable some instance just to build several variants/only one variant at a time. The above is an antipattern, which is a consequence of Makefile practice. Making easier to do that is against the best practices, and the change will not be made. --- The add_group() feature has a very particular usecase ("building a compiler before using it") which is not really for handling simple dependencies, and which breaks parallelism (slow compilations). Judging by the folder names you wrote, I not only think that those groups are unnecessary, but I also suspect uselib_local was not used. A workaround is to create the clones after each new group though. Nov 12, 2009 issue 563 (RFC: Permit to set the default build environment to avoid en...) commented on by julien.charbon - Good, thank for the "obj.posted = True" tip. Thus, if I try: ---- def build(bld): bld.add_subdirs('libs/js') # Change all tasks default env to current one [debug, optimize, ...] for obj in bld.all_task_gen[:]: obj_new = obj.clone('MYWANTEDDEFAULTVARIANT') obj.posted = True ---- It's work like a charm. But in my real case that doesn't work because doing this we loose all dependencies informations: My real case use dependency with add_group() : ---- def build(bld): bld.add_subdirs('libs/js') bld.add_group() bld.add_subdirs('src/tools') bld.add_subdirs('src/host') bld.add_subdirs('src/jslang') bld.add_subdirs('libs/nedmalloc') bld.add_subdirs('libs/libiconv') bld.add_group() bld.add_subdirs('src/jshost') bld.add_subdirs('src/jsdebug') # Change all tasks default env to current one [debug, optimize, ...] for obj in bld.all_task_gen[:]: obj_new = obj.clone('MYWANTEDDEFAULTVARIANT') obj.posted = True # Here we loose all task dependencies informations... :( ---- Thus open question: How to keep add_group() dependencies between tasks when cloning task? Currently I prefer my bld.setenv() call because of it's simplicity and that mirror the conf.setenv() call. But maybe that's not fit Waf main logic... Good, thank for the "obj.posted = True" tip. Thus, if I try: ---- def build(bld): bld.add_subdirs('libs/js') # Change all tasks default env to current one [debug, optimize, ...] for obj in bld.all_task_gen[:]: obj_new = obj.clone('MYWANTEDDEFAULTVARIANT') obj.posted = True ---- It's work like a charm. But in my real case that doesn't work because doing this we loose all dependencies informations: My real case use dependency with add_group() : ---- def build(bld): bld.add_subdirs('libs/js') bld.add_group() bld.add_subdirs('src/tools') bld.add_subdirs('src/host') bld.add_subdirs('src/jslang') bld.add_subdirs('libs/nedmalloc') bld.add_subdirs('libs/libiconv') bld.add_group() bld.add_subdirs('src/jshost') bld.add_subdirs('src/jsdebug') # Change all tasks default env to current one [debug, optimize, ...] for obj in bld.all_task_gen[:]: obj_new = obj.clone('MYWANTEDDEFAULTVARIANT') obj.posted = True # Here we loose all task dependencies informations... :( ---- Thus open question: How to keep add_group() dependencies between tasks when cloning task? Currently I prefer my bld.setenv() call because of it's simplicity and that mirror the conf.setenv() call. But maybe that's not fit Waf main logic... Nov 12, 2009 issue 562 (Absolute include paths coming from pkg-config are not used e...) Status changed by tnagy1024 - Status: Invalid Status: Invalid

issue 564 (cxx demo fails to compile) commented on by omnigoat - Aha. I took a look with -v, and noticed a flag IMPLIB was relative as opposed to /OUT's absolute (not actually a problem!). I MSDNed IMPLIB (http://msdn.microsoft.com/en-us/library/67wc07b9%28VS.80%29.aspx), and noticed that in the source files for the demo, there are no functions marked for export, and neither is the export command-line argument (/EXPORT) defined. LINK.exe is simply not generating the .lib files because it has decided it doesn't need to, effectively. I tested by modifying b2.cpp to include this line underneath the static integer: __declspec(dllexport) void do_nothing() {} And then rebuilt. This caused teshshlib.lib to be generated. shlib-1.lib, which does not use b2.cpp, remained absent. I then added this line to the bottom of d1.cpp : __declspec(dllexport) void do_nothing_twice() {} Both .lib files were generated, and compilation continued! However, line 49 in the wscript (demos/cxx/wscript) has 'uselib = MYPROG'. I'm unsure as to the intention of this, but it causes a problem: [31/44] cxx_link: build\debug\src\e1_5.o -> build\debug\src\program_dyn_linked.e xe 21:42:50 runner[33/44] system command -> ['C:\\Program Files\\Microsoft Visual Studio 8\\VC\\BIN\\LINK.exe', 'debug\\src\\e1_5.o', '/OUT:C:\\mywaf\\demos\\cxx\ \build\\debug\\src\\program_dyn_linked.exe', '/NOLOGO', '/MANIFEST', '/LIBPATH:d ebug\\src', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\ATLMFC\\ LIB', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\LIB', '/LIBPAT H:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\lib', '/LIBPATH :C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\lib', 'libteststaticli b.lib', 'shlib1.lib', 'testshlib.lib', 'm.lib'] cxx_link: build\default\src\e1_5.o -> build\default\src\program_dyn_linked.exe 21:42:50 runner system command -> ['C:\\Program Files\\Microsoft Visual Studio 8 \\VC\\BIN\\LINK.exe', 'default\\src\\e1_5.o', '/OUT:C:\\mywaf\\demos\\cxx\\build \\default\\src\\program_dyn_linked.exe', '/NOLOGO', '/MANIFEST', '/LIBPATH:defau lt\\src', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\ATLMFC\\LI B', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\LIB', '/LIBPATH: C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\lib', '/LIBPATH:C :\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\lib', 'libteststaticlib. lib', 'shlib1.lib', 'testshlib.lib', 'm.lib'] There's a rogue m.lib in there. It's never specified to be generated, and it's certainly not a system library. The removal of line 49 from the wscript results in a successful compilation of all the cxx demo. Looks like the demo needs to be cleaned up a little for Windows - I'm guessing the tools on linux cope with everything listed here fine. Ah well. Hope that helps.

Aha. I took a look with -v, and noticed a flag IMPLIB was relative as opposed to /OUT's absolute (not actually a problem!). I MSDNed IMPLIB (http://msdn.microsoft.com/en-us/library/67wc07b9%28VS.80%29.aspx), and noticed that in the source files for the demo, there are no functions marked for export, and neither is the export command-line argument (/EXPORT) defined. LINK.exe is simply not generating the .lib files because it has decided it doesn't need to, effectively. I tested by modifying b2.cpp to include this line underneath the static integer: __declspec(dllexport) void do_nothing() {} And then rebuilt. This caused teshshlib.lib to be generated. shlib-1.lib, which does not use b2.cpp, remained absent. I then added this line to the bottom of d1.cpp : __declspec(dllexport) void do_nothing_twice() {} Both .lib files were generated, and compilation continued! However, line 49 in the wscript (demos/cxx/wscript) has 'uselib = MYPROG'. I'm unsure as to the intention of this, but it causes a problem: [31/44] cxx_link: build\debug\src\e1_5.o -> build\debug\src\program_dyn_linked.e xe 21:42:50 runner[33/44] system command -> ['C:\\Program Files\\Microsoft Visual Studio 8\\VC\\BIN\\LINK.exe', 'debug\\src\\e1_5.o', '/OUT:C:\\mywaf\\demos\\cxx\ \build\\debug\\src\\program_dyn_linked.exe', '/NOLOGO', '/MANIFEST', '/LIBPATH:d ebug\\src', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\ATLMFC\\ LIB', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\LIB', '/LIBPAT H:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\lib', '/LIBPATH :C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\lib', 'libteststaticli b.lib', 'shlib1.lib', 'testshlib.lib', 'm.lib'] cxx_link: build\default\src\e1_5.o -> build\default\src\program_dyn_linked.exe 21:42:50 runner system command -> ['C:\\Program Files\\Microsoft Visual Studio 8 \\VC\\BIN\\LINK.exe', 'default\\src\\e1_5.o', '/OUT:C:\\mywaf\\demos\\cxx\\build \\default\\src\\program_dyn_linked.exe', '/NOLOGO', '/MANIFEST', '/LIBPATH:defau lt\\src', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\ATLMFC\\LI B', '/LIBPATH:C:\\Program Files\\Microsoft Visual Studio 8\\VC\\LIB', '/LIBPATH: C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\lib', '/LIBPATH:C :\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\lib', 'libteststaticlib. lib', 'shlib1.lib', 'testshlib.lib', 'm.lib'] There's a rogue m.lib in there. It's never specified to be generated, and it's certainly not a system library. The removal of line 49 from the wscript results in a successful compilation of all the cxx demo. Looks like the demo needs to be cleaned up a little for Windows - I'm guessing the tools on linux cope with everything listed here fine. Ah well. Hope that helps.

Yesterday

Last 7 days

Last 30 days