| 30 | | With this, the possibilities of improvement are huge, as will become easy to deal with debugging/analysing independent parts of code, without rely on restart whole bs scripting. |
| | 33 | With this, the possibilities of improvement are huge, as will become easy to deal with debugging/analysing independent parts of code, without rely on restart whole bs scripting. |
| | 34 | |
| | 35 | * '''Question from Greg Boone:''' Can you elaborate on the meaning of this statement in greater detail and further document the expected improvements that will result? What does “bs scripting” refer to? |
| | 36 | * auto*tools are not easy to write more else to change. From the point of view of final user, they runs the configure and done. But from the poiunt of view of maintenance, is a very difficult and complicated issue. Any process that need test and change something in a makefile needs regenerate whole auto structure. More dangerous is that we need to rely in multiple different versions of auto*toos provided on distros. In this specific case, dictate which libtool, automake, autoconf version is the fdo prefered won't be possible, because this is too sensitive for distros. The nature of cmake is way differently, since the simple text based buildfile, in no complex language ( similar a standard shell script ), and the easy ability to do out of source builds help in the matters that we can compile without polute source dir and change specific points in realtime not need to depend on many tools, like m4, automake, autoconf, libtoolize, etc.. |
| | 37 | |
| | 94 | |
| | 95 | == Questions from FDO Team === |
| | 96 | |
| | 97 | * '''From Greg Boone:''' What source code changes are being proposed, if any ? |
| | 98 | * Minimal changes are did. A undef in LLONG_MAX/MIN in !TestCommonConstraints.cpp to solve conflicts in linux/limits.h, A ifdef in !RegistryUtility.cpp to test FDO_LIBRARY_DIR and been able to load library in any user desired install, instead of using the ugly hardcoded "/usr/local/fdo-3.3.0/lib/" ( even in 3.3.1 ) and a int/long changee to x86_64 in !ClientServices/prefix.cpp |
| | 99 | {{{ |
| | 100 | #if defined(__x86_64__) |
| | 101 | if (((unsigned long) symbol) >= start && ((unsigned long) symbol) < end) |
| | 102 | #else |
| | 103 | if (((unsigned int) symbol) >= start && ((unsigned int) symbol) < end) |
| | 104 | #endif |
| | 105 | }}} |
| | 106 | |
| | 107 | * '''From Greg Boone:''' What installed content are being proposed as a result of the new build system? Can we get a comparison of the before/after result of building a full version of FDO and all it’s providers? What changes are applications expected to make in order to use the installed output? |
| | 108 | * The installed content is just more headers and libraries that are only static in past and now are installed and compiled as shared. I worked to not change anything as possible, just adding the necessary extra headers to enable providers to compile outside. I will provide an diff as soon as possible. |
| | 109 | |
| | 110 | * '''From Greg Boone:''' Can you give a brief outline of the source/build files that will be added/removed/modified in the SVN ? |
| | 111 | * Added |
| | 112 | * Subdirectory cmake with test files |
| | 113 | * CMakeLists.txt files for every subdirectory ( all txt files ) |
| | 114 | * Modified: |
| | 115 | * !ClientServices/prefix.cpp |
| | 116 | * !TestCommonConstraints.cpp |
| | 117 | * !RegistryUtility.cpp |
| | 118 | * Removed ( but not necessary during the transition ): |
| | 119 | * auto*tools related |
| | 120 | |
| | 121 | * '''From Greg Boone:''' Will the build_linux.sh files be maintained ? |
| | 122 | * Yes, if necessary. Now is way easier to build without the need of build_linux.sh. This give a wonderfull idea to add the build of thirdparty already on main cmakew scripts ( easy step too ) and just add simple instructions on documentation to build |
| | 123 | |
| | 124 | * '''From Greg Boone:''' Who will document the new build system for our users ? |
| | 125 | * The poor soul that write this own RFC ? :-) |
| | 126 | |
| | 127 | * '''From Greg Boone:''' On which Linux systems will the new build system be officially tested ? |
| | 128 | * From my side, i work for Mandriva as lead KDE team developer and core distro developer. I'm able to test ( and often have personal contact with some developers ) with Suse team and Red Hat team, so this can be what i can propose, Mandriva, Suse and RedHat/Fedora. I know that Ubuntu is a desired target too, a know personally some people working there and can try persuade some people to help, but my deep knowledge relied on Mandriva, Suse and Red Hat. |
| | 129 | |
| | 130 | * '''From Greg Boone:''' How are Windows .vcproj and .sln files generated from the cmake files ? How can custom .vcproj actions currently defined in the .vcproj files be captured by the cmake files ? |
| | 131 | * This can be answered by own cmake 2.6 documentation link [http://cmake.org/HTML/cmake-2.6.html#section_Generators Cmake Generators]. You will be surprised how many project types are supported. A simple cmake -G <generator> and done. The bidirectional issue of the second part of your question, i don't have immediate answer for this. |
| | 132 | |
| | 133 | * '''From Jason Birch:''' For instance, for user-installers of !FDO, does this allow for an easier build process across multiple Linux distributions, or even automated creation of installer packages (apt, yum, whatever)? For build managers, does it allow for the maintenance of Linux, VS2005, and VS2008 solutions in a central interface? |
| | 134 | * Yes, would be easy to even create packages, from the point of view of packagers. |
| | 135 | |
| | 136 | * '''From Jason Birch:''' What would be the effect on individual developers; would they have to install additional dependencies (for cmake)? Is cmake available across multiple platforms? |
| | 137 | * cmake itself doesn't depend on many things. As been available for all platforms, even more than current supported for !FDO, linux distros have at least the 2.4.x version available, and windows and mac have their own installer packages ready. |
| | 138 | |
| | 139 | * '''From Jason Birch:''' What kind of impact will this have on existing build procedures and end-user documentation for building FDO ? |
| | 140 | * For now, introiducing the cmake build as additional, will not impact in anything the current behavior. For end user documentation, see Greg's question above |
| | 141 | |
| | 142 | * '''From Jason Birch:''' I'm personally interested in cpack... do you have any experience with using this to create packages/installers for Linux and Windows ? |
| | 143 | * I did some small profiling in cpack yesterday, and yes, cpack can create easily withou almost no effort a suitable package to intall in linux, a nsis based install on windows. I did not tested rpm or deb, but i know is possible. The only issue about usage of this ones, is that usually distributions rely on their own policies for spec files. |
| | 144 | |
| | 145 | * '''From Greg Boone:''' How would a user build all of FDO, Utilities and Providers in the SVN ? |
| | 146 | * Simple steps for FDO core: |
| | 147 | * Create a build dir in any place ( really ) |
| | 148 | * Enter on dir |
| | 149 | * type cmake <yourbuilddir> |
| | 150 | * cmake test if all dependencies exists |
| | 151 | * type make |
| | 152 | * type make install. make DESTDIR=/my/test/dir install if you want a different install dir with same tree ( this is what packagers do ) |
| | 153 | |
| | 154 | * '''From Greg Boone:''' How would a user build a user-specified subset of FDO, Utilities and Providers ? |
| | 155 | * For fdo and utilities, enter on build dir ( see above ) the specified directory and type make. For providers, unpack the provider in any place and follow the same procedure as above |
