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.
I'm working on a codebase using make. The makefile looks like
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 Imake test. And when composer.lock does get changed, make knows to reruncomposer 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 installis run.Now make thinks that vendor is out of date, and will run
composer installeach time I need tomake test.I got around this problem by adding
touch vendorto the vendor target. This works around the problem, but it seems to me that this is something composer should be doing whencomposer installis run.