Drupal, Makefiles: save time, make awesome
| development, drupal, geekOne day I’ll post a generalized version of the Makefile that makes my Drupal life so much easier, but in the meantime, here’s the general structure I use:
- Lots of configuration settings:
- DB
- Database name for Drupal site
- DB_USER
- Database user for Drupal site
- DB_PASSWORD
- Database user password for Drupal site
- ROOT_DB_PASSWORD
- Root MySQL password, used to drop and recreate the database, and grant permissions
- SVN
- Subversion branch for source code control
- SVN_USER
- Subversion user name
- SVN_PASSWORD
- Subversion password
- SITE_DOMAIN
- Particularly useful when working with sites that use Domain Access, but handy even with other sites because of BASE_PATH
- SRC_DIR
- Location of source code, needed for Drush
- DRUSH
- Drush command line, just in case I want to fiddle with it
- DB_PREFIX
- Database prefix, for make clearcache
- BASE_PATH
- Base URL
- DRUSH_GROUPRE
- Regular expression to match against simpletests using my modified Drush_simpletest that lets me run all groups of tests matching a regular expression
- An include statement
- -include *.mk
- This is really useful. This lets you override the variables using a file like local.mk, dropped into your current directory and kept out of your source code control system. I use this to make my Makefile just Do The Right Thing when it’s in different directories or on different servers. Do not forget to tweak your included file (or make sure there is one) if you need different configuration settings.
- Lots of targets:
- backup
- Uses mysqldump to back up the database.
- restore
- Drops the database and restores it from the backup.
- clean
- Drops the database
- install
- Calls the site’s install.php with the appropriate profile.
- cron
- Calls the site’s cron.php
- mysql
- Starts a MySQL connection to the Drupal database. I don’t have to remember what the database name is or what the connection details are, hooray!
- clearcache
- Clears the {cache}, {cache_menu}, {cache_views}, {cache_content}, {cache_filter}, and {cache_page} tables
- revert
- Hits the panic button and reverts my tree. (because svn revert . -R is too long)
- tags
- Regenerate the TAGS file that lets me find function definitions really quickly
- test
- Use Drush to run all of my simpletest functional tests for this project
Sometimes I’ll have an “rsync” target to deploy files to a server and a “doc” target to regenerate my low-level documentation using doxygen, too.
This Makefile is seriously cool and seriously time-saving because it means that no matter which project, branch, directory, or server I’m working on, I have a consistent set of commands for the most common things I need to do. The less time I spend thinking about fiddly administrative tasks, the more time I can enjoy in the coding zone.
This is also one of the reasons why Drupal development is _so_ much easier on Linux or other Unix-ish systems, or even Microsoft Windows with the Cygwin environment. If you see yourself doing a fair bit of Drupal work, it’s well worth investing the time in setting up a virtual machine or a second partition, learning a new operating system, and re-setting-up your development environment.
make awesome. =)
What’s in your Makefile, or what other tricks do you use to increase your developer happiness?
11 comments
Peter Kelley
2008-12-05T00:28:04ZThe idea of a makefile is cool, it would certainly make life easier. My background is in Java and in Java there is a tool called ant which does essentially the same thing. I think that ant and Drupal would work really well together. The advantage of ant is that it is cross platform so you can use it on Windows, Linux, the Mac or Solaris.
I might have a go at setting up an ant build script for Drupal.
Wim Leers
2008-12-05T00:44:43ZWhy didn't I think of this yet?
Oh right, I didn't hink of it because makefiles are a complete mess. autoconf, configure, etc, it all feels so incredibly senselessly complex.
Thankfully, Qt does a much better job with its .pro files. Step 1: create a .pro file. Step 2: run qmake. Step 3: run make. That's at least understandable.
Then again, I might be wrong and I was only pointed to the most horrible tutorials.
This makes *so* much sense. I'd love to see this makefile, even if it were a stripped down version. Just to get a sense of what it looks like, to find out how easily extensible it is (if at all – forgive me my scepticism).
Very interesting post :)
Sacha Chua
2008-12-05T19:35:16ZOh, I haven't bothered with autoconf, configure, and all of these other things just yet. I use Makefiles as glorified shell scripts with variables I can change on the command line. =)
Wim Leers
2008-12-05T21:57:14ZSo actually it's not a Makefile, but a shell script that's called "make"?
Sacha Chua
2008-12-05T23:45:43ZNo, it's an actual Makefile, but it isn't autogenerated or anything of the sort. Just a bunch of variables, an include directive, and a bunch of targets. =)
randell
2008-12-05T04:45:41ZI'm blinded by awesomeness!
Carlo Pecchia
2008-12-05T08:12:11ZGenerally I prefer using Rakefile. I find it more clean and easy to read and maintain..
Drupal Themes Garden
2008-12-05T11:23:49ZNice.
Could you perhaps add source of your makefile (or some example), please?
EW
2008-12-05T14:40:24ZIt would be great to see this. Thanks!
Rob Russell
2008-12-12T13:44:04ZI'm voting for your session to see your makefile. How helpful are dependency rules? I come from the C world so make makes sense but did you look at other choices like Ant?
Sacha Chua
2008-12-12T14:18:09ZI use a few dependency rules to ensure sanity (can't do a restore without a database backup, etc.), but because PHP is interpreted, I tend to not have many dependencies to worry about. =)
I've shied away from using Java-based tools because (a) I'd been more used to writing shell scripts, and (b) Emacs + Firefox + the LAMP stack + Java = way too much memory used, it seems. But I should try translating my toolset to Ant - I'm sure I'll learn a lot along the way, and I'll probably pick up a few new ideas too!