So we could make the compilation conditional on a env parameter, and set that in the Jenkins job accordingly?
Note: the current build has already a condition "unless=isLinux". Does this mean Pixel Bender will not compile on Linux machines ? <target name="pixelbender-compile" unless="isLinux"> Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 10 décembre 2013 08:33 À : dev@flex.apache.org Objet : Re: [Builds/Jenkins] Help and advise needed We could take the pixel bender compilation out of the jenkins builds, but not our release package. It must contain the source and instructions for building it, and the binary package must contain that compiled source so folks don't have to compile it. The compiled pbj's should not be in the repo. Hopefully they were removed. -Alex On 12/9/13 11:26 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >Simple yet radical proposition: > >The pbk shaders didn't evolve much, and the compiled pbj are already >committed to the repo (although git history says they have been removed). >So couldn't we simply comment/strip "pixelbender-compile" from the build ? >If it ever happens to change, we could then recompile the pbj and >recommit. > >What do you think ? > >Maurice > >-----Message d'origine----- >De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 10 >décembre 2013 08:12 À : dev@flex.apache.org Objet : Re: >[Builds/Jenkins] Help and advise needed > >Remember, Gavin (builds@a.o) claim he changed nothing on the slave >that's now failing. I'm sure we didn't change anything on the Jenkins >job that is now failing. It isn't something in the SDK that's causing >this, lot's of people and the Mustella VM are building that regularly. > >Anyway: I'm not familiar with Pixelbender at all, is there some way we >can ask Gavin to test it on the slave that doesn't involve Jenkins? >Like a command line that he can simply copy-paste into a shell and give >us the results from? > >EdB > > > >On Tue, Dec 10, 2013 at 8:06 AM, Alex Harui <aha...@adobe.com> wrote: >> I tried to reproduce the failure on my machine but couldn't. I tried >> different path statements, removing the aif_* dlls, and changing >> execute rights on those dlls. I did find that the string "Internal >> Exception" is in the aif_core.dll. >> >> Not sure what to do next, but now I'm thinking: maybe nobody has seen >> this on their local computers? Only on the Jenkins Windows Slave and >> Windows VM? What do they have in common? What version of Windows >> are they running? What kind of graphics cards do they have? >> >> -Alex >> >> On 12/9/13 11:38 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: >> >>>On Dec 9, 2013 10:56 AM, "Alex Harui" <aha...@adobe.com> wrote: >>>> >>>> Ah, that thread looked like it was a year old. Did you work around >>>>it or just stop working on it? >>> >>>I just stopped working on it because I hit a dead end. I was >>>clueless as to how to fix it. >>> >>>> >>>> Other than checking the path, I don't have any ideas to try at the >>>>moment. >>>> >>>> On your Azure VM, if you manually launch the compiler from Windows >>>>command prompt you get this error, right? >>>> >>> >>>I will try it out tonight and let you know. >>> >>>Thanks, >>>Om >>> >>>> -Alex >>>> >>>> On 12/9/13 10:48 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> >>>>wrote: >>>> >>>> >On Dec 9, 2013 10:35 AM, "Alex Harui" <aha...@adobe.com> wrote: >>>> >> >>>> >> We keep hitting this error, but the mail archives do not >>>> >> document how >>>we >>>> >> fix it. This time, we should write down the answer. Om's hit >>>> >>it, Justin hit it, I think I had it once. The emails seem to >>>> >>indicate that it ispath related, but the build.xml does at least >>>> >>check if the pbutil.exe >>>>exists >>>> >> and is passing on that. >>>> >> >>>> > >>>> >In my case, I have not been able to fix it. In fact, if we are >>>> >trying >>>>to >>>> >reproduce the problem, we could use my Mustella VM on Azure and >>>> >see if >>>>we >>>> >can figure out what is happening. >>>> >We can then apply that fix to the windows1 slave on >>>> >builds.apache.org >>>> > >>>> >Thanks, >>>> >Om >>>> > >>>> >> I'll try to see if I can repro on my windows box tonight. >>>> >> >>>> >> -Alex >>>> >> >>>> >> On 12/9/13 12:16 AM, "Maurice Amsellem" >>>> >> <maurice.amsel...@systar.com> >>>> >> wrote: >>>> >> >>>> >> >Thanks Erik for the clarification. >>>> >> > >>>> >> >I confirm to you, I had to send the updated swc manually for >>>> >> >testing because the nightly build was down. >>>> >> > >>>> >> >Sorry, I didn't follow the thread from the beginning, so I >>>> >> >checked >>>>the >>>> >> >archives, maybe have missed something. >>>> >> > >>>> >> >I can see from the build logs that pixel bender build failed >>>> >> >and it >>>> >>seems >>>> >> >to be a path issue. >>>> >> >If that's correct, this is the path I am using on my local >>>> >> >build in >>>>my >>>> >> >env.properties: >>>> >> > >>>> >> >env.PIXELBENDER_HOME=C:\\Program Files (x86)\\Adobe\\Adobe >>>>Utilities - >>>> >> >CS5\\Pixel Bender Toolkit 2 >>>> >> > >>>> >> >I can see that in the build log, the path is: >>>> >> > >>>> >> >check-pixelbender-home: >>>> >> > [echo] PIXELBENDER_HOME is C:/Program Files >>>> >> >(x86)/Adobe/Adobe Utilities - CS5/Pixel Bender Toolkit 2 >>>> >> > >>>> >> >When I run it on my local env, it gives the following: >>>> >> > >>>> >> >[echo] >>>> >> >PIXELBENDER_HOME is C:\Program Files (x86)\Adobe\Adobe >>>> >> >Utilities >>>> >> >- CS5\Pixel Bender Toolkit 2 >>>> >> > >>>> >> >So maybe using "\" instead of "/" could fix the issue ? >>>> >> > >>>> >> >WDYT? >>>> >> > >>>> >> >Maurice >>>> >> > >>>> >> >-----Message d'origine----- >>>> >> >De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : lundi 9 >>>> >> >décembre 2013 08:53 À : dev@flex.apache.org Objet : >>>> >> >[Builds/Jenkins] Help and advise needed >>>> >> > >>>> >> >Hi, >>>> >> > >>>> >> >I'm having some difficulty getting the 'regular' builds on >>>>'build@a.o' >>>> >> >working. For those not subscribed to the builds list, the >>>> >> >situation >>>>is >>>> >>as >>>> >> >follows: >>>> >> > >>>> >> >- there are supposedly 9 admins for the windows1 slave, but >>>> >> >only one >>>is >>>> >> >sporadically active. I've requested access to the machine, but >>>> >> >got >>>>the >>>> >> >answer: "nine is enough." A suggestions there was actually only >>>> >> >one, >>>> >>with >>>> >> >8 ghosts fell on deaf ears. Apparently, it makes no sense to >>>> >> >remove >>>> >>old, >>>> >> >inactive admins and add new, active ones >>>> >> > >>>> >> >- since the windows1 slave is old, full and overworked, it >>>> >> >regularly >>>> >>went >>>> >> >down for days on end. We are one of the few projects that uses >>>> >> >the windows slaves, so I ended up being the guy who always >>>> >> >complains the slave is down... >>>> >> > >>>> >> >- the one active admin is now working on a second slave >>>>(windows2). >>>>In >>>> >> >itself, that is a very good thing. However, in his own words, >>>> >> >"he >>>feels >>>> >> >entitled to use our builds to experiment." I feel that is >>>> >> >wrong, >>>>but I >>>> >> >know better than to further aggravate my relation with him by >>>objecting >>>> >> >too strongly. >>>> >> > >>>> >> >The point of this elaborate introduction is this: somewhere in >>>> >> >his experiments he broke the Windows slaves for our builds. We >>>> >> >have not >>>> >>had a >>>> >> >successful build in a week. Normally, not that big a deal, but >>>> >> >with >>>the >>>> >> >third party IDE people working on FlexJS and the very active >>>> >> >mobile development both relying on nightly builds, I feel this >>>> >> >is not a >>>>time >>>> >>to >>>> >> >NOT have clean, daily builds of all our projects... >>>> >> > >>>> >> >Anything 'negative' I say on the builds list will certainly >>>> >> >make >>>things >>>> >> >worse - my NL temperament and lack of finesse often does not >>>> >> >sit >>>>well >>>> >> >with US recipients ;-) - so I would ask you to please chime in >>>> >> >on >>>>the >>>> >> >builds list and that we together get our builds back to >>>>functioning. >>>> >> > >>>> >> >Thanks! >>>> >> > >>>> >> >EdB >>>> >> > >>>> >> > >>>> >> > >>>> >> >-- >>>> >> >Ix Multimedia Software >>>> >> > >>>> >> >Jan Luykenstraat 27 >>>> >> >3521 VB Utrecht >>>> >> > >>>> >> >T. 06-51952295 >>>> >> >I. www.ixsoftware.nl >>>> >> >>>> >> > > > >-- >Ix Multimedia Software > >Jan Luykenstraat 27 >3521 VB Utrecht > >T. 06-51952295 >I. www.ixsoftware.nl
