On Wed, Jul 22, 2009 at 1:06 AM, Doug Gregor wrote: > On Thu, Jul 16, 2009 at 12:07 PM, Miguel A. Figueroa-Villanueva wrote: [...] > I haven't tried building the installer in a while and, at the moment, > I don't even have access to a Windows machine. But I'll see if I can > help!
Thanks. >> I'm getting the error output below when I run "CPack -G NSIS" >> [...] > > I have a very silly question: is there a variable "Python_headers" > somewhere in project.nsi? Python seems to be the only library that has > a capitalized module name, so I'm wondering if that's the issue... No, it doesn't and the patch below didn't work. Guess we couldn't get away with a free pass ;) [...] >> Now, I still have problems because when I run the installer it can't >> "download" the packages... I suppose that this is because the cpack >> process is not complete (note that if I run cpack again it overwrites >> the changes to the project.nsi and bails out with error again). > > The URL for downloading packages can be set in the configuration. When > the full CPack process completes, the CPackUploads directory will > contain a bunch of files that will need to be made available at that > URL. Alternatively, you can set the "monolithic" option to build all > of the packages into the installer itself. How do you set this monolithic option? By having BOOST_INSTALLER_ON_THE_FLY set to OFF? >> So, I guess my question is how do I go about solving this? What >> variable in the boost cmake files creates the dependency on the >> python_headers_* variables in the CPack/NSIS process? > > It starts with the cpack_add_* macros that get expanded from various > macros in Boost's tools/build/CMake/BoostCore.cmake. These macros set > many CPACK_* variables in CPackConfig.cmake, which are used by the > CPack process to create project.nsi. If the tiny patch at the end of > this doesn't help, then we'll need to trace through the CPack process > to see why the python_headers_* variables aren't getting created. Ok, I've traced the problem to the following: -- libs/python/CMakeLists.txt: is encapsulated in a "if (PYTHON_LIBRARIES)" -- libs/parameter/module.cmake states a dependency on the python lib So, I think the solution is to wrap the macro call in libs/parameter/CMakeLists.txt with the "if (PYTHON_LIBRARIES)"? BTW, does this mean that a header-only library (parameter) depends on a compiled lib (python)? > Oh, one question: did you build the "modularize" target and then > re-run CMake before building the NSIS package? That step is needed to > get all of the headers in the right places. Note that it pretty much > destroys your Subversion checkout, though, so perhaps do it on a copy > of your Subversion working copy. Yes, I modularized and re-ran... Thanks for your help _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
