Re: [Adobe-source-devel] CMake: Time to talk about requirements

[Foster B. <fbr...@ad...>]

On 30/05/09 8:25 PM, "Robert Dailey" <rcd...@gm...> wrote:

> Hey guys,
> 
> I've got a basic and functional first pass on my CMake implementation. I can
> successfully build, link, and run the Begin app, as well as ASL/APL. There's 2
> major steps we need to take from here.

Very cool!

> First, I need some of you guys to review my work so far. If this requires me
> moving my work to the review branch, I will do so. Please give me some
> detailed instruction on this if this is the path I am to take. I need you guys
> to try using CMake to generate the projects. None of you will need to become
> familiar with the CMake language at this point, you'll be working directly
> with the command-line client or the GUI interface (on windows). I want to
> gather opinions on the process, as well as potential suggestions for
> improvement.

Please add portions to the project's documentation regarding how to build
with the CMake scripts.

> Secondly, we need to figure out requirements. Improving the work I've already
> done is of course part of this, but we need to figure out long-term
> requirements, such as unit testing support and extensibility level of the
> scripts for future projects. There is also a particular topic we need to
> discuss. A typical approach to creating CMake scripts is to have a "root"
> CMakeLists.txt file that contains all of the inheritable, reusable code and
> other entities. For example, the root of the Perforce repository would look
> like this in a typical case:
> 
> //CMakeLists.txt
> //cmake/find_modules/FindTBB.cmake
> //adobe_source_libraries/CMakeLists.txt
> //adobe_platform_libraries/CMakeLists.txt
>
> Here, we define all of the reusable cmake functions, macros, and variables in
> CMakeLists.txt, and both ASL and APL CMakeLists.txt simply inherit those, and
> no explicit include() needs to be performed. However, the current structure I
> have is as follows:
> 
> //cmake/common.cmake
> //cmake/find_modules/FindTBB.cmake
> //adobe_source_libraries/CMakeLists.txt
> //adobe_platform_libraries/CMakeLists.txt
> 
> In this case, the root cmake directory still must exist. This cannot be
> removed. There is reusable CMake code that needs to be centralized in a
> location that both ASL and APL can get to, and one level above each of them is
> the best place for it that I know of. However, I've been told that no files
> can exist in the root (//), so I had to create //cmake/common.cmake that each
> of ASL and APL's CMakeLists.txt file must include, which increases the amount
> of boiler plate CMake code in each project-specific cmake script file.
> 
> This is one of the major issues we have to tackle. We, as a group, need to
> figure out what the best long-term hierarchical structure is for CMake. I also
> want to let you guys know that I do have a full time job. What that means to
> you is that I am most active on the weekends. However, this mailing list is
> extremely low traffic and my biggest bottle neck right now is getting feedback
> from the rest of the team. Not to rush, but if you guys could respond more
> often (especially on weekends), I would be able to get a little bit more done.
> I can only do so much work without thorough requirements.

Thanks for all the work you've done so far. I'm most active during the week
(indeed, I'm quite inactive on the weekends as far as work goes :-) ) and
while I can't speak for Sean or Mat I'm sure their situations are similar.
We're definitely not as high bandwidth as we'd like to be, so your patience
is definitely appreciated.

I agree that we need to figure out a good long-term hierarchical structure
for CMake. As I said before it's quite a bit of support to add another depot
for the cmake scripts. We've been successful in integrating the boost build
system into ASL/APL and I'm wondering if a similar solution can be
implemented for the CMake contributions.

Another idea that would be very helpful would be to see what Boost is doing
with CMake (they're developing a parallel build solution to bbv2) and try to
mimic their designs as reasonably as possible. Decisions made by precedent
(especially when the precedent is Boost) tend to have a lot of weight.

Blessings,
Foster


-- 
Foster T. Brereton                <ἰχθύς><                Ro 3:21-26
  Computer Scientist 2 --- Photoshop Engineering --- Adobe Systems
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov