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.

CommentFileSizeAuthor
#1 1109002-make-subdir-default-1.patch671 bytessime

Comments

sime’s picture

StatusFileSize
new671 bytes

And the patch

dman’s picture

I'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?

sime’s picture

I 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/bar you have to do two things. 1) call drush with --contrib-destination=sites/foo and 2) set the subdir in .make file with projects[example][subdir] = bar

The "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.

dman’s picture

That'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!

dmitrig01’s picture

Status: Active » Closed (works as designed)

Use drush make-3.x

sime’s picture

Swweeet, didn't even know there was one.

marcvangend’s picture

Thanks 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.

patcon’s picture

FYI The patch can be applied manually to drush 5.x make command when you find the corresponding file. :)

patcon’s picture

Project: Drush Make » Drush
Version: 6.x-3.x-dev »
Component: Code » Make
Assigned: sime » Unassigned
Status: Closed (works as designed) » Patch (to be ported)

Can we consider whether this is appropriate for drush 5.x? The fix still works when done manually

jhedstrom’s picture

Status: Patch (to be ported) » Closed (duplicate)

I 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.