like http://drupal.org/project/geofield, leaflet could provide a make file for automatic configuration (download the leaflet javascript library).

see http://drupalcode.org/sandbox/dasjo/1408378.git/commit/refs/heads/7.x-1....

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nottaken’s picture

create a leaflet.make with something like this..

; $Id$

api = 2

core = 7.x

projects[] = libraries
libraries[leaflet][download][type] = "get"
libraries[leaflet][download][url] = "https://github.com/CloudMade/Leaflet/tarball/master"
libraries[leaflet][directory_name] = "leaflet"
libraries[leaflet][destination] = "libraries"

levelos’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

adamdicarlo’s picture

Title: Provide a make file » Provide a make file; avoid being recursively built
Status: Closed (fixed) » Needs review
FileSize
1.32 KB

The makefile should not end with .make because Drush Make automatically picks it up when building a site from a makefile, and I end up with "libraries" in my modules directory (*as well as* in modules/contrib), even though my makefile itself indicates libraries to go into "contrib". I think the standard approach now is to include a .make.example file (e.g., geofield).

Follow-up patch attached.

dasjo’s picture

i would be interested if can you post a reference, that this is a "standard approach now".
otherwise we could also file an issue for drush make in order to have it behave correctly.

adamdicarlo’s picture

I don't have any references; I noticed that geofield module does it this way to avoid the same problem, so it seemed like the way to go. Though you have a point about adding a --no-recursion option to drush make. That might be a better solution.

I'll ping jhedstrom (drush make maintainer) about this on Monday.

jhedstrom’s picture

Unfortunately, due to the way drush make currently handles recursive builds, there is no way for the end developer to override options or parameters specified in remote .make files. As such, moving these to foo.make.example has become a sort of informal standard, if only until make can handle overriding remote make files easier.

For a bit more background on this, see the rules issue about the same thing.

dasjo’s picture

thanks for the background info.
seems like the way to go for now

pvhee’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.