Re: [Adobe-source-devel] stlab's SHA on github

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

I'll add the patch to the legacy development branch then. The unit test is
relatively comprehensive though I don't think every API is quite covered
yet. That can be resolved as well. As for documentation I'll look at the
header and see what I can clean up.

For both the doxygen docs and tests there is a lot of cruft currently in
the repository. Are we willing to break a lot of what's in there in favor
of the new world order, or is it worth creating a development branch in
the adobe source libraries depot and build from scratch?

Blessings,
Foster


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






On 12/13/12 4:25p, "Sean Parent" <sp...@ad...> wrote:

>
>On Dec 13, 2012, at 4:05 PM, Foster Brereton <fbr...@ad...> wrote:
>
>
>I have a patch to make to the sha.hpp header in ASL and figure it would be
>a good time for me to dip my toes in ASL on github. I'm thinking it would
>be a good place to start the module style on github as its a single header
>file that depends only on adobe/config.hpp and three boost headers.
>
>What's the process of "promoting" an ASL component to the github module
>structure?
>
>git modules aside and based on what Boost is doing, I'm thinking a sha/
>repo with:
>
> - sha/include/adobe/sha.hpp
> - sha/test/jamfile.jam
> - sha/test/main.cpp
>
>
>
>The boost module structure isn't quite usable yet (at least I wasn't able
>to get it going). I decided to hold off a bit here. What I'd like to do
>is to start migrating files out of the legacy repo into the
>adobe_source_libraries repo.
>
>Basically, rebuild things in the form of boost 1.52.0 for now - but I
>only want files going into adobe_source_libraries that have:
>
>1) A good unit test (I'd like to ensure full code coverage - but haven't
>yet setup tooling for that).
>2) Clean docs (the current docs aren't even close to building with latest
>doxygen).
>
>Let's _not_ submit built docs to this repo -  we should do that to a
>pages repo but that isn't setup yet.
>
>I'm in the process of cleaning up unicode.hpp cause imagecore/video needs
>this (I'd like to just redo it to use the C++11 unicode support but
>imagecore still needs to support C++03 for a bit longer). I'm doing the
>work in /legacy/development and then planning to move it into
>/adobe_source_libraries when it is cleaned up.
>
>Any suggestions to bend this to be more forward looking is welcome as
>well.
>
>Sean
>
>
>
>(SHA already has its own ASL test.)
>
>A couple questions:
> - I could add a docs folder but it'd be empty - maybe a placeholder .md
>or .html in there?
> - I'm guessing config.hpp needs to go into its own module? 'common' with
>just the include?
> - How are dependencies established between submodules? The jamfiles will
>have to be updated to include each dependency module's include path
>separately, which will immediately break if/when ASL is glommed back
>together again a la the official boost releases. How is the disparity
>between module folder structure and distribution folder structure handled?
>
>Blessings,
>Foster
>
>
>--
>Foster T. Brereton                  ΙΧΘΥΣ                  Ro.3:21-26
>Senior Computer Scientist   ---   Photoshop Engineering   ---   Adobe
>
>
>
>
>
>
>
>
>Sean Parent
>sp...@ad...
>
>“Simplicity and elegance are unpopular because they require hard work and
>discipline to achieve and education to be appreciated.” - Edsger W.
>Dijkstra
>
>
>
>
>
>
>