Re: [zeta-dev] PHP based build system : Phing VS Pake
Sebastian Bergmann wrote: Am 20.04.2011 09:30, schrieb Jerome Renard: I would say the main problem with Ant is there is no loops and conditionals I have never needed programming structures like that in my build automation scripts. But I think I understand where the problem is: you are trying to use a build automation tool to implement an application: a website generator. This is wrong. What you want to do may be possible with Pake (or any build automation tool that supports build scripts with a cyclomatic complexity 1) but that does not make it right ;-) I surely feel like a troll in asking this, but where exactly is stated that build automation tools should not use loops and conditionals? The venerable 'make' surely did allow them - and I see fail to see any added value in removing the possibility of using them. To me, the main downside to make is the fact that tasks have to be written using shell code, which is neither really portable nor fun. Ant is surely more portable, but even less fun. And every build script becomes an application-generator application in the end (just as every application grows to the point where it can send mail ;-) ) Have a look at how the documentation for PHPUnit's manual is built [1]. There are a couple of PHP scripts that deal with syntax highlighting of examples and form a website from the HTML that comes out of DocBook/XSL. But the automation of these scripts happens in Ant. As it should be. -- [1] https://github.com/sebastianbergmann/phpunit-documentation Basically the ant file you use is a container for invoking external commands. Since it contains no logic or complexity at all, it makes a good point in case for using ant. But it could have been written in pake using exactly the same amount of lines / commands. And pake allows to do the more complex stuff, that you put in external php scripts, either in-process or out of process. The advantage would thus be that you need . no editing of xml files . a single runtime environment (no java) . knowledge of a single language (php) for editing the build config . no separate build tool + application-generating application Ciao Gaetano
Re: [zeta-dev] PHP based build system : Phing VS Pake
Am 20.04.2011 09:30, schrieb Jerome Renard: I would say the main problem with Ant is there is no loops and conditionals I have never needed programming structures like that in my build automation scripts. But I think I understand where the problem is: you are trying to use a build automation tool to implement an application: a website generator. This is wrong. What you want to do may be possible with Pake (or any build automation tool that supports build scripts with a cyclomatic complexity 1) but that does not make it right ;-) Have a look at how the documentation for PHPUnit's manual is built [1]. There are a couple of PHP scripts that deal with syntax highlighting of examples and form a website from the HTML that comes out of DocBook/XSL. But the automation of these scripts happens in Ant. As it should be. -- [1] https://github.com/sebastianbergmann/phpunit-documentation -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/
Re: [zeta-dev] PHP based build system : Phing VS Pake
Jerome Renard wrote: Hello, I started to test Pake in the context of AZC. You can get the Pakefile if you svn up website/ You may also browse the file here: - https://fisheye6.atlassian.com/browse/zetacomponents/website/Pakefile?r=1091818 As you will see it is quite simple et much more readable that its Ant equivalent. Glad we share the same impressions ;-) Any feedback welcome :) One thing: I see you have set the path to cli tools in config file. While this allows some flexibility, it means the config file will need to be different if running the build on my windows pc and on your mac. I propose instead to make the config file oblivious to the environment, and use options passed on the cli for environment-related parameters, eg php pake.php thistask --php=/usr/local/bin/php --doxygen=c:/program files/doxygen/bin/doxygen.exe Also remember to use escapeshellarg() around your command line executables and paths before invoking them. There might be spaces in them... Bye Gaetano
Re: [zeta-dev] PHP based build system : Phing VS Pake
Gaetano, On Thu, Apr 14, 2011 at 11:23 AM, Gaetano Giunta giunta.gaet...@gmail.com wrote: Jerome Renard jero...@apache.org wrote on 14/04/2011 11:11: [...] I believe you can define environment variables on Windows: - https://fisheye6.atlassian.com/browse/zetacomponents/website/Pakefile?hb=true#to150 Sure enough - albeit it's not as common to do it as it's on unix. Ok. I still prefer cli options than env vars for 90% of the time though, as it's easier to understand what is happening when the options are explicit. But, as far as I can see in your code, what you can do is that you can swap out one config file with another. What I was asking to is to separate cofig options: one set that is project-specific (stored in the config file), and one set that is specific to the build environment (passed via cli options or env vars). I'll see how to pass arguments from the command line in Pake then. -- Jérôme Renard http://39web.fr | http://jrenard.info | http://twitter.com/jeromerenard
Re: [zeta-dev] PHP based build system : Phing VS Pake
On 04/14/2011 11:36 AM, Jerome Renard wrote: I still prefer cli options than env vars for 90% of the time though, as it's easier to understand what is happening when the options are explicit. But, as far as I can see in your code, what you can do is that you can swap out one config file with another. What I was asking to is to separate cofig options: one set that is project-specific (stored in the config file), and one set that is specific to the build environment (passed via cli options or env vars). I'll see how to pass arguments from the command line in Pake then. I'd suggest to use some kind of properties file for configuration. At least that is what we do when using ant. Our scripts ship with a build.properties file and the script itself looks for build.local.properties. If this doesn't exist, it bails out with a message that the user should copy and adjust the original file. This way is pretty convenient and most obvious I'd say. Cheers, Toby -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] PHP based build system : Phing VS Pake
Tobias Schlitt wrote: On 04/14/2011 11:36 AM, Jerome Renard wrote: I still prefer cli options than env vars for 90% of the time though, as it's easier to understand what is happening when the options are explicit. But, as far as I can see in your code, what you can do is that you can swap out one config file with another. What I was asking to is to separate cofig options: one set that is project-specific (stored in the config file), and one set that is specific to the build environment (passed via cli options or env vars). I'll see how to pass arguments from the command line in Pake then. I'd suggest to use some kind of properties file for configuration. Yaml is the pake-equivalent of properties. Is it fine with you to have yaml files for config? At least that is what we do when using ant. Our scripts ship with a build.properties file and the script itself looks for build.local.properties. If this doesn't exist, it bails out with a message that the user should copy and adjust the original file. This way is pretty convenient and most obvious I'd say. Kind of ok, but why not instead: - take properties from build.properties file (which is complete) - if build.local.properties is there, use it to override existing properties (if it's not where, just continue) This way there is no need to copy files around, and the original properties file can be kept in sync easily with the upstream svn/git version.
Re: [zeta-dev] PHP based build system : Phing VS Pake
Hi Alexey, thanks for your feedback. On Wed, Apr 13, 2011 at 10:40 PM, Alexey Zakhlestin indey...@gmail.com wrote: [...] Any feedback welcome :) line 30: I'd use pake_echo_comment() instead. same for other similar lines Fixed. lines 94-117: 1) I'd use pake_sh($command, true) Fixed. 2) don't forget to use escapeshellarg() where appropriate Yep, I will take care of that later. lines 134-137: pake_mkdirs($targetDir, 0755); // no need for if. pake take cares of that Fixed lines 139-149: pake_copy($tarball, $targetDir.'/'.$options['build.name'].'.tar.bz2'); Fixed lines 142-143: pake_remove_dir($options['build.dir'] . '/phpdoc/'); Fixed lines 243-245: pake_rename( $HTMLFile, dirname( $HTMLFile ) . '/' . $newHTMLFile ); Fixed pake's versions of basic filesystem-functions are good because: 1) they do nothing, if nothing has to be done (won't try to delete non-existant file, won't copy file if source is older than target) 2) they report what they do to console as the result, you have to type less code Yep that is what I noticed, and that gave me a couple of ideas to enhance ezcBaseFile Thanks :)
Re: [zeta-dev] PHP based build system : Phing VS Pake
Hi, On Tue, Apr 12, 2011 at 6:49 PM, Gaetano Giunta giunta.gaet...@gmail.com wrote: As I proposed pake in the 1szt place, no need to assert any more that I like it enough. +1 from here as well. We use Pake anyway for Midgard packaging and installation. So at least Zeta Components have already been installed on a bunch of machines via Pake ;-) /Bergie
Re: [zeta-dev] PHP based build system : Phing VS Pake
- is not XML based (Derick will appreciate that :P) probably the only one ;-) I will try to give Pake a try as soon as possible. But if one of you already has experience with Phing or Pake I would be happy to get your feedback about these tools :) I have no experience and no preference with Pake and Phing, but I could understand Phing very quickly (no surprise, as a ant user) and had some trouble to get into pake. I am still unsure on some points and could not use it straight away. You'll probably need to make a good documentation on Pake otherwise I can imagine that users who want to join the project might have some trouble. I don't see a benefit compared to the actual makefile in readability. If you say, Pake is easier - its just in the eye of the observer. this is the auto flagellation part I plead guilty for imposing Ant, the reason is that I have been using it for a couple of years already and I thought it would solve problems we got in the Makefile. But I was wrong. this was the auto flagellation part Naaa, Ant is not such bad! Trying it out was a logical consequence. It just didn't fit
Re: [zeta-dev] PHP based build system : Phing VS Pake
Christian Grobmeier wrote: - is not XML based (Derick will appreciate that :P) probably the only one ;-) Not sure if this is a joke, but xml simply has to die (TM). I will try to give Pake a try as soon as possible. But if one of you already has experience with Phing or Pake I would be happy to get your feedback about these tools :) I have no experience and no preference with Pake and Phing, but I could understand Phing very quickly (no surprise, as a ant user) and had some trouble to get into pake. I am still unsure on some points and could not use it straight away. You'll probably need to make a good documentation on Pake otherwise I can imagine that users who want to join the project might have some trouble. Not a good doc by any stretch, but to hit the ground running: ?php pake_desc( 'docs for the next registered task' ); pake_task( 'init-me' ); // registers task init-me // another task pake_desc( 'Builds the extension' ); // registers task build-me, depending on init-me. // dependencies are not managed as make would do (ie. looking at file timestamps). init-me is always run 1st when build-me is executed pake_task( 'build-me', 'init-me' ); // function invoked when executing task 'init-me' // $args and $opts come from the parameters passed via cli, similar to what a -Dthis.property=that would do in ant. // The complete syntax is: // php pake.php [generic-pake-options] task [specific-options] [arguments] // so that eg running php pake.php init-me --skip-this --this=that andmore // would results in $opts = array( 'skip-this' = true, 'this' = 'that' ) and $opts = array( 'andmore' ) function run_init_me($task, $args=array(), $opts=array()){ echo 'hello'; } function run_build_me($task, $args=array(), $opts=array()){ echo 'world'; } ? I don't see a benefit compared to the actual makefile in readability. If you say, Pake is easier - its just in the eye of the observer. this is the auto flagellation part I plead guilty for imposing Ant, the reason is that I have been using it for a couple of years already and I thought it would solve problems we got in the Makefile. But I was wrong. this was the auto flagellation part Naaa, Ant is not such bad! Trying it out was a logical consequence. It just didn't fit
Re: [zeta-dev] PHP based build system : Phing VS Pake
- is not XML based (Derick will appreciate that :P) probably the only one ;-) Not sure if this is a joke, but xml simply has to die (TM). No joke. And XML has some good benefits. I don't want it to die. Probably I am oldschool. Not a good doc by any stretch, but to hit the ground running: pake_desc( 'docs for the next registered task' ); pake_task( 'init-me' ); // registers task init-me pake_desc( 'Builds the extension' ); pake_task( 'build-me', 'init-me' ); function run_init_me($task, $args=array(), $opts=array()){ echo 'hello'; } Thanks, so far I understood - similar code can be found in the docs. Still I cannot see why this is better than XML. But I believe its a matter of view and taste. Maybe - if Zeta uses Pake - I will learn more and use it myself. Cheers Christian
Re: [zeta-dev] PHP based build system : Phing VS Pake
On Tue, Apr 12, 2011 at 11:31 PM, Christian Grobmeier grobme...@gmail.com wrote: And while we are at it, consider to join the incubator.apache.org with pake. I am pretty sure there are some supporters around. I wouldn't mind seeing Pake and some other stuff from Alexey - like the AppServer in PHP project - under the Apache / Zeta Components roof. At least AiP is PHP 5.3-only, though. That might be an issue? BTW, here is a bit more complex Pake example, the Midgard MVC installer we use: https://github.com/midgardproject/midgardmvc_installer /Henri