Re: [Adobe-source-devel] CMake support: Work in Progress

[Robert D. <rcd...@gm...>]

Sean,
Thanks for getting back with me about this. First of all I just want to
mention that while this is a work in progress, its existence does not
interfere with anything else currently in the repository. You will see a
couple of CMakeLists.txt files lying around, but you are under no obligation
whatsoever to use it. I'm letting you know this because even though CMake is
not entirely usable yet, having it checked in for "backup purposes" does not
hurt anything.

The benefits CMake provides are quite substantial, but to mention a few:

   1. It provides a portable way of generating projects. For example:
      - On Windows, you can generate Visual Studio projects (there are of
      course other choices as well)
      - On Linux, you can generate Makefile scripts (There are also other
      options)
      - On Mac, you can generate XCode projects (There are, again, also
      other options)
   2. There are multiple IDE's and build systems support *per platform*
   3. CMake can easily handle unit tests, and also supports the use of
   CTest. Benefits include:
      - CMake allows you to define a project as a unit test, which allows
      CMake to know which executables to run when testing is executed. It will
      neatly report to you the results of all of the unit tests.
      - Compile pass/fail unit tests are outside of the scope of CMake.
      These can be automated using Boost. Since a unit test that fails
to compile
      will be treated as any normal project, this should work fine. While CMake
      only facilitates runtime unit testing, it does not prohibit compile time
      unit testing in any way that I am aware of.
      - Optionally, unit test results can be posted to a server where unit
      test results can be reviewed remotely in a nicely formatted, color-coded
      HTML web page. I have not worked with CTest much for this, but
it isn't hard
      to learn. I know that the system itself exists and can be very useful for
      continuous integration.
   4. With some extra work, cross-compilation is also supported by CMake.
   For example, if you ever wanted to port ASL to a mobile platform, like the
   IPhone or Symbian, this would be a useful feature.
   5. CMake provides all of the idioms of a typical language, such as
   functions, macros, and other things. This allows you to generalize your
   CMake scripts so the process of defining a project or unit test is just a
   few lines of code.
   6. CMake scripts are arguably less tedious to configure than Visual
   Studio directly, or other IDEs and build systems

I could list more, but those are the biggest benefits that come to mind.

I feel that CMake will be a far better alternative to bjam because it will
allow the developers to choose a visual IDE for development if they wish. I
personally can't stand compiling things from command line when I work with
them on a daily basis (Like my personal projects and ASL). There's nothing
better than giving the developer the option as to how they want to compile
the code instead of saying "Here's bjam. Learn to use it. Learn to love it".

Starting out, the CMake scripts will be relatively simple, and inevitably
restrictive. Providing a unique and generic unit testing system and complex
project creation will take several continuous iterations. For someone not
really maintaining CMake, they don't have to care about the "heavy" logic,
since it will be modularized and placed in a location outside of your
typical work environment.

Getting CMake to behave exactly as your team requires will require some
collaboration and (obviously) requirements. Right now, I'm doing the basics
and making a few assumptions as well. For a functional and satisfactory
long-term solution, you and I (and maybe others) will need to discuss
requirements. CMake is even flexible enough that we may have to even do a
bit of analysis/design as well.

One of the most important requirements is getting an idea of how developers
would like to interface with CMake for tasks such as creating projects and
unit tests. Some programmers like the idea of unit tests not being something
explicitly defined. In this case, the directory structure would be set up in
such a way that each "project" has a "tests" directory under it (or
something similar). This makes unit tests predictable, which in turn allows
you to automate their construction.

Via phone conference or mailing list discussion, in the future, I would be
happy to discuss the long-term goals for a build system. However, for now, I
consider anything I contribute as far as CMake is concerned prototypical. I
want to get something up and running that functions in a minimal way
(Perhaps just simple projects are created with or without unit tests). When
I'm done, I would expect a full review to evaluate CMake's eligibility as a
build system and perhaps discuss any further requirements.

Depending on how complex the CMake system gets (and it will get complex if
your requirements are vast), it could become a full-time job. I will most
definitely be able to always help with its maintenance, but I would expect
other people on the project (That includes you, Sean) to become as familiar
with it as they can/want to. It always helps to have other people pitch in.
I'm going to be working on my open source Layout Editor for ASL in parallel
with my contributions to ASL (Through CMake and perhaps C++ later on).

I definitely love adobe, and I really love what you guys have done with ASL.
It's an extremely promising concept that I've never seen before. I really
look forward to contributing in whatever ways that I can.

Please let me know if I can answer any more of your questions. I am far from
the expert at CMake, but I have used it quite a lot and I'm familiar with
most of its general functionality.

On Tue, May 19, 2009 at 6:39 PM, Sean Parent <sea...@ma...> wrote:

> Hi Robert,
>
> I'd be happy to set you up with a developer account on our perforce server.
> Before accepting a CMake system I'd want to know what complexity it adds and
> what benefits it provides.
>
> Currently we use bjam because it works with boost, and allows us to
> construct and execute unit tests with a fairly simply, unit tests can be
> specified to compile or fail to compile, or run or fail to run. The ability
> to do both positive and negative test cases are important. We minimally
> maintain the IDE projects largely because I prefer to develop in an IDE.
>
> If you're willing to maintain a CMake environment and it provides some
> benefit to the community without too much complexity then we can roll it in.
>
> Thanks,
> Sean
>
>
> On May 17, 2009, at 8:47 PM, Robert Dailey wrote:
>
>  Hey guys,
>>
>> Just letting you know that I have a first pass complete on my CMake build
>> system for Adobe's ASL/APL libraries. Currently, I can successfully generate
>> a visual studio 2008 project using CMake. This project will build a static
>> library of ASL only. I'm currently in the process of writing the logic for
>> APL, which is going to be nearly identical. After that, I need to support
>> the begin app. My goal is to keep the "look and feel" the same as with the
>> checked in visual studio project in msvc_ide.
>>
>> I'm flying though this pretty quickly, as there really hasn't been much
>> work to do so far. I can compile the library successfully so far with an
>> unpatched version of Boost 1.39 and TBB.
>>
>> I would like to be able to commit my work to Perforce, but from the little
>> reading I did, contributions are a rather complex process at Adobe. I would
>> rather one of the developers let me know how to contribute my work, if you
>> even want it.
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables
>> unlimited royalty-free distribution of the report engine
>> for externally facing server and web deployment.
>>
>> http://p.sf.net/sfu/businessobjects_______________________________________________
>> Adobe-source-devel mailing list
>> Ado...@li...
>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>>
>
>