On 12/19/13 3:24 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote:
>>I'm proposing that the pixelbender.xml only contains the "main" target >>as the release policy only seems to require instructions on how to >>compile the source, not necessarily create a >release. The >>release-pixelbender target will remain in the main build.xml >OK. > >Another question, you said: >>adding a pixelbender.xml file with a main target that does the compile, >>a clean target that deletes the PBJ and a copy target that >> copies the PBJs into place in the sdk tree. > >I don't understand this step. > >I may have understood wrongly, but it seems that you are proposing two >ways of having the PBJ into the SDK: > >1) directly, by compiling the PBK and storing the PBJ in place in the SDK >tree. > This is how it works now, and this option can be done only if window/gpu >are avaible > >2) indirectly, by downloading the released pixel-bender package from dist >repo. >This is to be done when window/gpu is not available, eg. when running the >build on Jenkins without a service. > >Is that correct ? Not quite, I am proposing a third way. Justin pointed out there should be an approved method of using the PBJ's if you work from a source package. If you expand the source package into the flex-sdk tree, or build the source package and copy the entire tree into the flex-sdk tree, the NOTICE, README and RELEASE_NOTES files in the top-level folder would be overridden. So, the "copy" target will copy the PBJ files. We could instruct folks to use flags to not overwrite files, but that's probably too error prone. But we could also try to instruct folks to simply point to the compiled source package and not have this third option. -Alex
