[DOCS-7228] Document changes to the build system Created: 23/Feb/16 Updated: 21/Oct/16 Resolved: 20/Oct/16 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ryan Schmidt | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 7 years, 18 weeks ago |
| Description |
|
Hello, I'm the maintainer of mongodb in MacPorts, trying to update our port from 3.0.8 to 3.2.3. In 3.0.8, we were running scons with --cc=/usr/bin/clang --cxx=/usr/bin/clang++ --c++11 and --libc++. In 3.2.3, the first three arguments do nothing. --c++11 was presumably removed because it was mandatory anyway, and --cc and --cxx are now specified with CC and CXX. But there was nothing in the documentation to tell me this. I did eventually find confirmation about it here: https://groups.google.com/forum/m/?fromgroups#!topic/mongodb-dev/cq6bOrKl2Hw In 3.0.8, we were also running scons with --cpppath=/opt/local/include and --libpath=/opt/local/lib. This also does nothing in 3.2.3. This must now be specified with CPPPATH and LIBPATH. I found nothing in the documentation about this. scons --help does not say anything about these changes. In your release notes, change log, wherever, please document changes to your build system. It seems like every time I update to a new version of mongodb, or any software built with scons, I waste hours figuring out how to make things work again. I wish you would switch from scons to a build system that is not so unpredictable, such as autotools, or at least stop changing your build system every version. |
| Comments |
| Comment by Andrew Morrow (Inactive) [ 12/Oct/16 ] |
|
I appreciate that the build system changes are disruptive, but the fact is that we are in a gradual process of entirely re-writing it, exactly so that we end up with something simpler and more useable, and eventually able to be documented. The original MongoDB build system of the 2.4/2.6 vintage was very poorly factored and had several severe design problems. In general, we have not documented the build system beyond what is available via 'scons --help`, since we know that it will be constantly in flux. There is probably one more big push during the next MongoDB development cycle leading to MongoDb 3.6, however, we don't expect the interface to the build system to change that much in that work - the projects are more focused on the internals. I think that once we have the build system we want, it would make sense to try to document it better, but to be honest it is not high on our list of priorities. As far as switching to another build system - autotools is not going to happen, because it doesn't work on Windows. We have looked at CMake in the past, however, we did not feel that the move to CMake came with enough benefits to justify the change. So, we will be sticking with SCons. Note that the changes that you observed were not due to changes in SCons itself, but due to our adjusting our build system to more properly make use of the features that SCons offers. SCons is enormously flexible and allows us to develop the build system in directions that we do not believe would be easily achieved using CMake. Our experiences developing the mongocxx driver (the new C++11 driver) with CMake have in fact solidified our decision around SCons. |