Sorry Alex, I missed you proposition in the last email (this interleaved multithreaded discussions are a real pain...) > Right now, I'm thinking of: > 1) 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. > 2) add more to the release notes that point you to this xml file > 3) Separate NOTICE > 4) tagging flex-sdk repo > 5) Add git location to README (actually describe how this is a subset > of > flex-sdk) > > You'll still use release-pixelbender from the main build.xml to create > the package.
I don't understand the steps. You say that the new "pixel-bender.xml" does the compile and copies the PBJ into the SDK trees. What's the difference with the release-pixelbender that will create the package. Does it mean there are two ways of compiling the PBK? One to make the PB package, and another one directly inside the SDK, like it works currently ? Maurice -----Message d'origine----- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mercredi 18 décembre 2013 23:43 À : dev@flex.apache.org Objet : RE: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2) Justin is right, anyway I didn't have the intention to veto the release ;-) First of all, thanks Alex for the consideration you give to my position, given that I am a newcomer to the team. If you think that #1 (leave the files in place) is good solution, then go for it. I just would look to precise how I understand it would work, and tell me if you agree: File organization: - PBK files stay where they are, in the current flex-sdk git repo - There is a specific target eg. "build-pixel-bender-release" in the build.xml that builds the PBJ release: - compiles the PBK => PBJ - makes a zip file of the PBJ and maybe other file (LICENCE, README, etc...) Note: This special target does not need to be called when building flex-sdk) Process to build the PB release (including manual tasks): - the "PB release builder" checks out the whole flex-sdk repo on his PC - calls the target "build-pixel-bender-release" - copies/commits the resulting zip to dist/... - calls for voting of the release. Note: this is open-source, so anyone who would want re-build the PB release would also call this target, Manual or Jenkins FLEX-SDK build: - sdk build.xml includes a new task/target to download/unzip the PB release (including the PBJ) from dist and copy them to the right place. Is that OK? Did I miss something? Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 18 décembre 2013 22:37 À : dev@flex.apache.org Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2) On 12/18/13 9:48 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >> >>Well, I am making it a separate package. The question is whether you >>think we should also move this code out of the flex-sdk repo. >What does "separate package inside the flex-sdk" mean? >is that a distinct and autonomous directory inside the flex-sdk repo, >much like "mustella" or "modules" ? >If it's that, then yes, that should be fine, as far as there is no >direct dependency on the flex sdk build. Currently the files are where they have always been. All I did was modify some build scripts. Looks like there are at least 3 options: 1) leave the files in place 2) move the files to a new folder in flex-sdk repo 3) move the files to flex-utilities Doing #1 appears to be the least work, but if you are going to veto the release then I need to find some other configuration that will make you happy. > >>Another thing to consider: What if the PB compiler stops working on >>Windows or Mac someday due to an OS incompatibility? When we don't >>own the tools and the tools are not under active development, we run a risk. >>Who knows when Adobe would respond. I think PB compiler was last >>shipped in Creative Suite 5.5. >Yes, that's a possibility. >Maybe another way of looking at it would be to consider not the support >for pixel-bender compiler, but rather the support of *PB inside the >FlashPlayer*. >So all the time Adobe supports PB shaders, we will have our >"voted/validated" release of pre-compiled PBJ, that will not evolve, >and that we can continue shipping and its guaranteed to work. >Simply consider them as "frozen legacy Adobe stuff", which it is >already de-facto. Remember, we are an open-SOURCE project so everything we do needs compilation or interpretation. An official Apache release contains source code and instructions to build it and that sort of implies that the tools work. -Alex
