Alissa Sabre wrote: >> So far most of the changes have been for delaying download of prebuilt >> binaries to build time. > > I'm not sure my environment is typical or unusual, but my main > development machines are not online (i.e., disconnected from Internet) > usually. I connect those machines only when necessary. In a past, my > practice was something like: download necessary files with another > machine and copy those files to main development machine locally. > These days, however, I need to connect my main development machine to > internet when running develop.py. I have a feeling you are making > things worse, i.e., I would need to connect my main development > machine whenever I build...
If the files are up to date it should see them in your download cache and not actually touch the network. You only need to be connected for the initial build, and then only for building the 'prepare' target. > What is the primary reason of this change? What advantage does the new > scheme have over the current one? Previously the initial run of CMake took a long time before one could interactively change any options. Now it is really fast, and all the long stuff is delayed until build time which does not require further interaction. >> (building without flex/bison). > > This sounds good, especially I'm still having a bison related issue on > MacOS. I'm afraid, however, that this change makes it difficult to > modify .y and/or .lex files. Hope your change actually means > "flex/bison are not needed unless the builder changed .y/.flex files, > and if she/he changed, flex/bison runs automatically to update > generated .cpp/.hpp files." > > # Am I hoping too much? If you have flex and bison installed then it will use them and generate the files. This makes interactive development easy. Before committing, though, one needs to manually run flex and bison using the instructions in comments at the top of the sources. One must commit the input files and output files at the same time. Otherwise if a user builds without flex or bison he/she will get an out-of-date parser. This extra effort for the developer is traded for simplifying the build for users. Dropping cygwin as a dependency of windows builds is a win. >> We've already planned enhancements to CMake's >> command-line usability for a later phase of this effort. This includes >> project-specific command-line options like --standalone. > > So, you are changing CMake itself? Great! We plan to make a few tweaks to CMake's interface, mainly to ease command-line usage. The issues you raise below are out of the scope of this effort. I'll briefly comment on them, but this is not the place for full discussion of CMake-specific topics. > Following is a list of my own wishes on CMake improvement that I > believe facilitte SL development: > > Proper handling of platform-specific file system features. E.g., on > MacOS, a mount point for Windows (SMB/CIFS) file server has a > semicolon (;) character embedded in it, but the current CMake can't > handle such full-path name. The CMake language use ';' as a list separator. This cannot be addressed without major fundamental changes that are incompatible. > Or, on Windows, file names are case > insensitive but CMake seems file names case sensitive ways, causing > trouble if the SL source files are placed in a lo0cation whose > full-pathname contains upper-case letters. My Second Life sources are in ".../My Programs/SecondLife/linden" on windows and it works fine. > Avoid coding full-paths and options on Linux. I have a feeling that > CMake likes to embed full-paths to, e.g., compilers and other tools or > fully expanded command line options to the build tools in the > generated makefile's Changing compilers in an existing build tree is not a case we optimize. If one does change the compiler, everything needs to rebuild because CMake cannot be sure the new compiler provides an identical ABI. That's why we support out-of-source builds. Just create as many build trees as you have compilers, and you never need to change compilers in an existing build tree. > Fine build dependency. I also have a feeling, although not sure, that > the CMake generated build files contain unnecessary build > dependencies. A significant effect of this is tyhat, when any of the > library subprojects failed to build, any source files in the newview > directory are not compileed and the build process stops. Because > those libraries are only needed upon linkage, steps before linkage > should happen. CMake takes a conservative approach here. It is possible that one of the libraries to which an executable links contains a custom command to generate a header file that will be included by some of the executable's source files. If the library has not finished building before we start to compile the executable's sources then the header may be missing or out of date. I suggest running 'make -i' to ask make to keep going despite failures. > Another observation is that when modifying a header > file in a library subproject, a lot of source files that doesn't use > the modified header file are re-compiled. I'll be surprised if this is the case. Next time it happens, try preprocessing the object that you don't think should have rebuilt to see if it uses the modified header. You can also run "make -d" to see why it decides to rebuild something. > A related _wish_ to easybuild is a co-existance of standalone and > non-standalone build directory based on a single source tree. This is a develop.py limitation. CMake has full support for truly out-of-source builds. Just create your own build trees and run CMake directly. -Brad _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
