I have a module that includes a makefile. The makefile's sole purpose is to make the library download easy. However, when I do nothing to the projects array in the makefile, I get the error "No core project specified". I briefly tested this in 3.x-dev and got the same results. This makefile dies:

core = 7.x
api = 2

;phpCAS
libraries[phpCAS][download][type]= "file"
libraries[phpCAS][download][url] = "http://downloads.jasig.org/cas-clients/php/current.tgz"
libraries[phpCAS][directory_name] = "phpCAS"
libraries[phpCAS][destination] = "libraries"

Yet this one succeeds:

core = 7.x
api = 2

projects[cas][subdir] = "contrib"

;phpCAS
libraries[phpCAS][download][type]= "file"
libraries[phpCAS][download][url] = "http://downloads.jasig.org/cas-clients/php/current.tgz"
libraries[phpCAS][directory_name] = "phpCAS"
libraries[phpCAS][destination] = "libraries"

I think it's a bug, but if not, please let me know what I'm doing wrong.

CommentFileSizeAuthor
#3 1159548-no-core-recursion-3.patch515 bytespwolanin

Comments

pwolanin’s picture

pwolanin commented

Having exactly the same problem - I can make the single file work by passing --no-core, but when it's part of an install profile and invoked via recursion it fails.

Seem that drush make needs possibly to use the no-core flag once it starts a recursion?

pwolanin’s picture

pwolanin commented

example:

apachesolr downloaded from http://ftp.drupal.org/files/projects/apachesolr-6.x-1.4.tar.gz.      [ok]
Found makefile: apachesolr.make                                                                                         [ok]
No core project specified.                                                                         [error]
SolrPhpClient downloaded from http://solr-php-client.googlecode.com/files/SolrPhpClient.r22.2009-11-09.tgz.[ok]
calendar downloaded from http://ftp.drupal.org/files/projects/calendar-6.x-2.4.tar.gz.              [ok]
pwolanin’s picture

pwolanin commented
Status: Active » Needs review
StatusFileSize
new 1159548-no-core-recursion-3.patch515 bytes

Here's one approach that seems to work.

dmitrig01’s picture

dmitrig01 commented
Status: Needs review » Fixed

thanks

the_g_bomb’s picture

the_g_bomb commented
Status: Fixed » Reviewed & tested by the community

Seconded, patch goes in fine and solves the issue

pwolanin’s picture

pwolanin commented
Status: Reviewed & tested by the community » Fixed
the_g_bomb’s picture

the_g_bomb commented

Surely this shouldn't be fixed until it is merged into the project. Reviewed and tested means its ready to be added to the project and should become part of the next release.

justintime’s picture

justintime commented

@the_g_bomb - it wasn't really explicitly explained, but pwolanin's patch has actually been committed into the dev branch. Once the code's been committed, usually the status is set to fixed.

the_g_bomb’s picture

the_g_bomb commented

Sounds good, just didn't realise it had been committed, thanks

Status: Fixed » Closed (fixed)

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

dmitrig01’s picture

dmitrig01 commented

... committed to 6.x-3.x

travisc’s picture

travisc commented

The patch works, drush make is borked without it, any way to roll a new version soon to save others the confusion?

skwashd’s picture

skwashd commented

As noted in the release notes, this patch was also included in 6.x-2.3 released last week.

drzraf’s picture

drzraf commented
Version: 6.x-2.x-dev » 6.x-3.x-dev
Priority: Normal » Major
Status: Closed (fixed) » Active

It happens to me (with a more complex makefile), I found that while 2.x works well, 3.x does *not*.
I bissected this to aba3eca2d970e0d4c85bdc8ad3c2f8843e26626e which changes things in-depth.
I also checked that the simple makefile in comment #1 stopped to work after this commit.

The parser was broken when it went into its own file.
I suspect a bug when handling '#' commented lines; eg:

core = 7.x
api = 2
projects[media][type] = "module"
projects[media][download][type] = "git"
projects[media][download][branch] = "7.x-2.x"

versus

core = 7.x
api = 2
# this LINE HERE
projects[media][type] = "module"
projects[media][download][type] = "git"
projects[media][download][branch] = "7.x-2.x"

When running both with eg, drush @mysite make --verbose --no-core themakefileabove.make /tmp/X you'll see how the second case fails silently.

the parser needs to be fixed in some way.

helmo’s picture

helmo commented
Status: Active » Closed (won't fix)

[ Powered by #1115636: Issue Macros and Templates - Drush Make]

Drush make is being merged into drush core (discussed in issue:#1310130: Put drush make in drush core)
This means that the issue queue is also moving. The Drush project has a component called 'Make' for this purpose.

We would like to take this opportunity to leave behind old/obsolete issues, allowing us to focus on a stable make command in core. E.g. one of the major tasks ahead is making more use of the Drush core code for handling downloads and decompression.

If you feel that this issue is still relevant, feel free to re-open and move it to the Drush queue.

More information will be posted on the drush_make and drush project pages.

drzraf’s picture

drzraf commented
Status: Closed (won't fix) » Active

it's still relevant: I can reproduce this consistently (as in comment #14)

helmo’s picture

helmo commented
Project: Drush Make » Drush
Version: 6.x-3.x-dev »
Component: Code » Make

Then let's move it to the new queue.

dww’s picture

dww
we/he/they
commented
Status: Active » Fixed

Re: #14, #16:
'#' isn't a comment in make files. ';' is. This is basically ini syntax (like .info files), not PHP or shell syntax, etc.

I don't think there's still a bug here.

drzraf’s picture

drzraf commented

You're right, and according to http://php.net/manual/en/function.parse-ini-file.php, php 5.3 enforces the '#' rejection by default...
but still mysterious as drush make does not use parse_ini_file but instead the home-made make_parse_info_file function, which wraps _drush_drupal_parse_info_file.

The later uses a big preg_match_all
Is there any strong reason of not using parse_ini_file ?

dww’s picture

dww
we/he/they
commented

@drzraf: This is totally off topic for this thread, but the reason is that drush .make files (like drupal .info files) are close to .ini syntax but not exactly conforming. The primary difference is the nested array syntax, but there are probably other cases where our pseudo-ini syntax differs from the what parse_ini_file() can handle.

Cheers,
-Derek

Status: Fixed » Closed (fixed)

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