Much as I love the dream of auto downloading libraries with themes there are situations where including a naked make file will break platform builds.*

I'd suggest renaming blueprint.make to blueprint.make.example to avoid problems, this was the solution for colorbox module too (see http://drupal.org/node/839580#comment-4075174 ). And I've made a similar suggestion for ckeditor module: http://drupal.org/node/1011178#comment-4250124

* case in point: today I'm doing a new platform build to update blueprint, amongst others, and have an error:

blueprint downloaded from                                                            [ok]
http://ftp.drupal.org/files/projects/blueprint-6.x-2.0.tar.gz.
Found makefile: blueprint.make                                                       [ok]
You need to specify an API version of two in your makefile:                          [warning]
api = 2
No core project specified.                                                           [error]

Basically this makefile doesn't work with drush-7.x-4.4 / drush_make-6.x-2.2 (due to drupal.org infrastructure changes I think, post git migration). End result is that my platform build fails and I now have to fiddle about either pinning blueprint module to an earlier release, or creating a custom branch to pull in with my own make file, just so I can update.

+1 for having an example make file, but an auto running one is too inflexible and when it breaks, the breakage propagates far beyond blueprint.

Comments

EugenMayer’s picture

EugenMayer CreditAttribution: EugenMayer commented

iam seconding the approach. Make files are actually for developers and site builders. When people start to use make files, they will now about drupal, drush and make files deeply. So there is no need to "simplify" the make file process in general, as those people now how to do this ( read the deps, add the libs, done ).

having an example file even makes it easier, but please dont call it like a make file. This way you force all people using this module to use this makefile ( due to recursion ). They cannot use different version or "patched" own version, similar. You cannot switch the recursion of for "some" module and if some modules arbitary start to add those make files, this kind of creates a new big choas.

So having a blueprint.make.example would be just perfect for both cases. +1 for it :)

shrop’s picture

shrop CreditAttribution: shrop commented

I just had the same issue with a make file which pulls blueprint.

I agree with the rename of blueprint.make to blueprint.make.example.

Thanks!
shrop

seanr’s picture

seanr
he/him
CreditAttribution: seanr commented
Priority: Normal » Critical

Yeah, same problem here. Really bad move, because it completely breaks my platform on Aegir. Can we please get this fixed sooner rather than later? It's September now!

designerbrent’s picture

designerbrent CreditAttribution: designerbrent commented
Version: 6.x-2.0 » 6.x-2.x-dev

Sorry for the long delay. This change has now been committed to the dev version.

designerbrent’s picture

designerbrent CreditAttribution: designerbrent commented
Status: Active » Needs review

I just created a new release for this fix that is 2.1 so that should put this issue to rest.

That said, for those of you that use make files, the idea has been raised privately that if we removed the "core = 6.x" line, it wouldn't break the rest of the install when the make file is there, download the library code and not throw the errors it has been giving. In light of that, I have committed the make file back to the 2.x version and am wondering if anyone would be willing to test it there and see if it works. I don't have the time to test it right now but if someone else who is using this would be able to give it a shot, that would be great.