Re: [Adobe-source-devel] Moving ASL to github

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

I have taken a stab at this and made notes in the legacy/development
branch accordingly.

The BOOST_NO_CXX11_NUMERIC_LIMITS macro not being defined seems to be a
Clang support issue within boost/config. It's being defined appropriately
when the toolset is darwin (gcc-4.2.1)

Note: Using Apple's dev tools using clang is now a requirement given the
use of c++11 features that only exist in gcc versions 4.4 or later. Xcode
4.5.2 uses a flavor of gcc 4.2.1. I'm sure Sean and Mat are aware of this,
but I wanted to call it out explicitly. Of course if you're building with
a version of gcc that supports the c++11 features used, you're in the
clear.

With bjam I haven't been able to figure out a way to force the entire code
base of Begin to build with the x86 architecture. The command line I've
been using is:

    bjam -a release -j8 address-model=32

Note: -a is a force-rebuild of all sources and is optional. -j8 specifies
8 concurrent compilation processes for my 8-core machine; YMMV.

Blessings,
Foster


--
Foster T. Brereton                  ΙΧΘΥΣ                  Ro.3:21-26
Senior Computer Scientist   ---   Photoshop Engineering   ---   Adobe






On 11/8/12 8:51p, "Sean Parent" <sea...@ma...> wrote:

>I've move the migration page on the wiki
><http://stlab.adobe.com/wiki/index.php/GitHub_Migration_and_Status> and
>updated the status.
>
>Assistance from anyone with experience in bjam and/or cmake would be
>greately appreciated at this point (see the status).
>
>Sean
>
>
>On Wed, Nov 7, 2012 at 3:02 PM, Sean Parent <sea...@ma...> wrote:
>
>Feel free to fork - splitting into modules is going to take some time.
>-----
>
>First up is any_regular.hpp
>   Issues with the current implementation to be addressed:
>       1) reliance on promote<> - promote<> seemed like a good idea but
>it has bit me a number of times, currently longs promote to double, which
>is just wrong. It also means that the interface needs to be value based
>in many locations where it could have been reference based. Will add a
>build flag to tag places where promote would have kicked in to help with
>migration.
>       2) needs to be updated to C++11 move, and remove dependency on
>move library.
>       3) assignment - currently requires assignment, this is an issue
>because I'd like to make function objects and lambda's first class (or as
>close as possible) but equality is very useful. I have been playing with
>ways to write a has_equal_to<> that seems to work good enough.
>       4) implementation and interface complicated by ABI stability. ABI
>stability to be removed (but I will be moving to using inlined
>namespaces).
>       5) implementation complicated by use of poly<> - plan to remove
>that.
>       6) rename to adobe::any
>       7) make constructor implicit
>       8) rename explicit_cast and runtime_cast to static_cast_ and
>dynamic_cast_ to make them easier to remember.
>
>
>Open issues:
>       1) Match boost::any api including broken any_cast interface?
>(differs from boost::any by support small object optimization, optional
>equal_to, and unsafe static cast). boost::any has been proposed to the
>standard - and the broken any_cast has already been discussed to be fixed.
>       2) Add support for other operators - such as index by std::size_t
>or const char* (useful for dictionaries and arrays), arithmetic operators
>for numeric types?
>
>Suggestions? Comments?
>Sean
>
>
>
>On Wed, Nov 7, 2012 at 2:01 PM, Ivan Le Lann <iva...@fr...> wrote:
>
>
>
>________________________________________
>
>De: "Sean Parent" <sea...@ma...>
>À: ado...@li..., "Mat Marcus"
><mm...@em...>, "Foster Brereton" <fbr...@ad...>
>Envoyé: Mercredi 7 Novembre 2012 01:37:03
>Objet: Re: [Adobe-source-devel] Moving ASL to github
>
>I setup a section on our wiki to document the transition to github. That
>can be found here:
>
>http://stlab.adobe.com/wiki/index.php/Github_migration
>
>
>Not a lot there at the moment - but should be enough to get people
>started.
>
>
>
>
>Thank you for doing this.
>I will definitely base my (utterly slow) work on ASL on this repository.
>
>As I do not understand anything to Perforce, merging with .43 release has
>been somewhat painful.
>
>
>
>
>
>As modules are split out and cleaned up I plan to propose them for
>inclusion in boost as appropriate.
>
>
>
>
>
>
>
>
>
>
>Does that mean that forking is not recommended at the moment and until
>modules are split ?
>
>Regards,
>Ivan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>