Re: [Adobe-source-devel] Question about building ASL

[Mat M. <mat...@em...>]

On Sat, May 16, 2009 at 5:00 PM, Robert Dailey <rcd...@gm...> wrote:

> According to the instructions for building ASL, one must restructure the
> libraries in a certain way in order for everything to build correctly. I
> personally am very opposed to this, as it requires renaming and moving my
> other libraries, such as TBB and Boost. If this is currently the only way
> things can be done, then I plan to take the time to configure CMake to build
> ASL and APL.

One should be able to do this with appropriate modifications to the
boost-buildv2 Jamfile.v2s. I spent a little moving n this direction
some time back, but the effort was driven more from a desire for
theoretical path independence than from an actual client request.

My goals/desires are:
>
> Be able to build ASL independently of APL.

This is already the case for the normal developer scenario when
building from the command line.

> When building APL, ASL is a required dependency (if I am understanding
> correctly).

Yes, APL depends on ASL. Under the boost-build system, applications
that depend on APL automatically depend on ASL. I believe this is true
of library artifacts as well as include paths (via the bbv2
usage_requirements facility).


> CMake will configure ASL to build first, and then APL will build after.
> Third party libraries such as boost and TBB (And ASL for APL) are not
> required to be in any specific relative position from the library that
> depends on them.

It was not boost-build that requires TBB and boost to be in a specific
position relative to ASL/APL. It was my limited time/knowledge of how
to write the appropriate Jamfile.v2s.

> They may be in any location on the filesystem. A minor bit
> of configuration will be required in order to tell CMake where to find these
> paths. This configuration can be done on the command-line, which is
> especially useful for automated builds.

For the Adobe use cases, it was important to keep initial
configuration to a minimum. I believe that both sets of use cases can
be accommodated, perhaps by assuming certain relative paths by
default, while also allowing user-configuration/overrides.

> Once such a system is set up, I would expect the ASL and APL root
> directories to contain names consistent with linux library naming
> conventions. For example, a library with a tarfile like this:
>
> fubar_1.0.41.tar.gz
>
> would extract into a directory like this:
>
> fubar_1.0.41
>
> Currently, asl_1.0.41.tgz extracts into "source_release", which is
> unsatisfactory

Yes, it would be good to improve the current naming conventions--they
are an unfortunate artifact of the brittleness of the current
net-install scripts.

>
> I will await word back from someone on the ASL/APL project (more
> specifically, Sean) before delving into this work. I want to make sure that
> the build method for ASL/APL is more flexible than it appears.
It sounds like most of what  you want can be accomadated under the
develpoer scenario by improving the boost-build Jamfile.v2s for the
project. This is not to say that a port from bbv2 to CMake wouldn't be
an eventual improvement to ASL. But I expect that I won't want to make
that switch until boost officially does.

> Thanks for reading. Please respond back soon!

Thanks for your interest and questions.

 - Mat