Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should composer play nice with make? #2764

Closed
mtibben opened this issue Feb 26, 2014 · 2 comments
Closed

Should composer play nice with make? #2764

mtibben opened this issue Feb 26, 2014 · 2 comments
Labels
Milestone

Comments

@mtibben
Copy link

mtibben commented Feb 26, 2014

I'm working on a codebase using make. The makefile looks like

vendor: composer.lock
    composer install

test: vendor
    ./bin/phpunit

This works well, because make knows that in order to run phpunit, it should build the vendor directory by running composer install. Once it has been run once, make knows that the timestamp of vendor is greater than composer.lock, so doesn't need to run it again if I make test. And when composer.lock does get changed, make knows to rerun composer install.

The problem occurs when composer.lock changes with a trivial change (e.g. the description might be changed) which means that composer doesn't need to do anything when composer install is run.

Now make thinks that vendor is out of date, and will run composer install each time I need to make test.

I got around this problem by adding touch vendor to the vendor target. This works around the problem, but it seems to me that this is something composer should be doing when composer install is run.

@Seldaek Seldaek added this to the Nice To Have milestone Feb 26, 2014
@Seldaek
Copy link
Member

Seldaek commented Feb 26, 2014

Makes sense, and it should now work but please let me know if that's not what you meant.

@mtibben
Copy link
Author

mtibben commented Feb 26, 2014

Thanks very much @Seldaek !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants