I have dealt with a few make files that do this for every project:
projects[views][subdir] = contrib
projects[devel][subdir] = contrib
; etc, etc
This patch allows the setting of a flag that can be overridden.
subdir = contrib
; These will go to .../contrib
projects[] = views
projects[] = devel
; These will go to .../custom
projects[quirky][subdir] = custom
This makes large .make files much prettier and easier to visually digest.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 1109002-make-subdir-default-1.patch | 671 bytes | sime |
Comments
Comment #1
simeAnd the patch
Comment #2
dman commentedI'm looking for answers to something like this.
When working with a makefile in an install profile, that then recursively gets more (and recursively more), EVERYTHING ends up in the /profiles/{profile}/modules/ directory.
To be normal (and to be able to reliably use drush dl and things for further development) I really want all my stuff in sites/all/modules/contrib.
Unless otherwise stated.
If I set a [subdir] argument on the modules that are downloaded as part of a profile install, they still end up in under the profile directory.
Is there a way around this? Will this patch - setting a default directory - approach help that?
or will the profile install root still be in effect? If so, is there another issue anyone has looked at this issue in?
Comment #3
simeI don't think I can solve your issue, but I can say that Drush Make treats the "contrib destination" and the "subdir" as two separate things.
So in order place a module called "example" in the path
sites/foo/modules/baryou have to do two things. 1) call drush with--contrib-destination=sites/fooand 2) set the subdir in .make file withprojects[example][subdir] = barThe "module" part of the path is dynamically determined.
The help says that the contib destination defaults to sites/all, so I doubt you can fix your situation by using the --contrib-destination argument. It's probably worth opening another issue but please add a link here if you do.
Comment #4
dman commentedThat's incredibly helpful. That option sounds like the one I'm looking for.
... but didn't do the trick for me, as you suspected.
When running
drush --contrib-destination=sites/all make --working-copy /var/www/mysite/mysite_2011_install.make.bootstrap(where mysite_2011_install.make.bootstrap is a makefile that just says where to fetch the profile from)
... All modules were still built under the profile tree.
Ah well, worth a try, thanks!
Comment #5
dmitrig01 commentedUse drush make-3.x
Comment #6
simeSwweeet, didn't even know there was one.
Comment #7
marcvangendThanks for "fixing" this issue, but what's the status of Drush Make 3.x? There's no sign of it except for a 5 months old branch in the git repository...Edit: Nevermind, sorry, I forgot. Drush make is being merged into Drush 5.
Comment #8
patcon commentedFYI The patch can be applied manually to drush 5.x make command when you find the corresponding file. :)
Comment #9
patcon commentedCan we consider whether this is appropriate for drush 5.x? The fix still works when done manually
Comment #10
jhedstromI just opened #1633050: Create defaults array in .make files for specifying attributes common to all projects today, what a coincidence. I didn't find this issue when searching, but I think the approach there is more general. Marking this as a duplicate.