-j опция make GNU
Можно использовать quickfix режим, как после
:set errorformat=%f
:cf myfilelist
в этой точке, можно использовать нормальные quickfix ярлыки для прохождения через файлов, :cn для следующего файла, :cp для предыдущего и :cr для движения в первое снова.
РЕДАКТИРОВАНИЕ:
, о, если Вы хотите прочитать список из текущего буфера, использование :cb вместо :cf в в инструкциях выше
4 ответа
Я думаю, make -j будет учитывать зависимости, указанные в вашем Makefile; т.е. если вы укажете, что objA зависит от objB и objC, то make не начнет работать с objA до тех пор, пока objB и objC не будут завершены.
Скорее всего, ваш Makefile не определяет необходимый порядок операций достаточно строго, а просто удачи, что это сработает для вас в однопоточном случае.
Если у вас есть рекурсивный make, все может довольно легко сломаться. Если вы не выполняете рекурсивный make, то, пока ваши зависимости правильные и полные, вы не должны столкнуться с какими-либо проблемами (за исключением ошибки в make). См. Рекурсивная программа make считается вредной для более подробного описания проблем с рекурсивной программой make.
Короче говоря - убедитесь, что ваши зависимости верны и полны .
Если вы используете однопоточную программу make, вы можете слепо игнорировать неявные зависимости между целями. При использовании параллельной программы make нельзя полагаться на неявные зависимости. Все они должны быть явными. Это, наверное, самая распространенная ловушка. В частности, при использовании целей .phony в качестве зависимостей.
Эта ссылка является хорошим руководством по некоторым вопросам, связанным с параллельным make.
Вот пример проблемы, с которой я столкнулся, когда начал использовать параллельные сборки. У меня есть цель под названием «свежий», которую я использую для восстановления цели с нуля («свежая» сборка). Раньше я кодировал «свежую» цель, просто указывая «очистить», а затем «построить» в качестве зависимостей.
build: ## builds the default target
clean: ## removes generated files
fresh: clean build ## works for -j1 but fails for -j2
Это работало нормально, пока я не начал использовать параллельные сборки, но с параллельными сборками он пытается выполнять как «чистую», так и «сборку» одновременно. Поэтому я изменил определение «свежий» следующим образом, чтобы гарантировать правильный порядок операций.
fresh:
$(MAKE) clean
$(MAKE) build
По сути, это просто вопрос правильного определения зависимостей. Хитрость в том, что параллельные сборки более строгие, чем однопоточные. Мой пример демонстрирует, что список зависимостей для данной цели не обязательно указывает порядок выполнения.