Я использую node-gyp для создания собственного дополнения Node.js, написанного на C++ в Linux.Вызов make from node-gyp
Это дополнение зависит от другой общей библиотеки. Эта библиотека в настоящее время не построена с помощью gyp, у нее просто есть make-файл.
Если я сначала создаю общую библиотеку, тогда создайте мое дополнение, указав значение для «библиотек» в главной цели в моем файле binding.gyp, все работает нормально.
Однако, что бы я хотел , как, чтобы сделать, это создать общую библиотеку из источника из процесса node-gyp, вызвав make в файле make-файла общей библиотеки. Я попытался добавить зависимую цель, используя свойство «действия» для этого дополнения в binding.gyp и делает основной мишенью зависит от него:
{
"target_name": "other_library",
"type": "none",
"actions": [
{
"action_name": "build_other_library",
"inputs": [],
"outputs": [ "/path/to/build/output/libother.so" ],
"action": [ "make", "-C", "/path/to/makefile" ]
}
]
}
Это не полностью работает. Это : обнаружение другого make-файла и make запускается (я вижу, что это происходит с -verbose set), но make-файл не выполняется должным образом.
Кажется, что правила неявной сборки GNU make подавляются, когда выполняется make-файл для общей библиотеки. Это означает, что файлы .cc и .cpp не компилируются в .o-файлы.
Я понимаю, что node-gyp сам генерирует набор make-файлов для надстроек из целевых объектов в binding.gyp, а файл make-файла разделяемой библиотеки генерируется из одного из них.
Наследует ли настройки make от node-gyp, включая подавление встроенных правил?
Есть ли способ вокруг него? (Помимо добавления явных правил сборки в файл make в общей библиотеке)?
(Я попытался заменить make на $ (MAKE), это не имело значения).
EDIT:
Запуск GNU сделать на разделяемую библиотеку с указанной опцией -d из оболочки (т.е. вне узла лавочка), поиск неявного правила для типичного исходного файла выглядит следующим образом:
Considering target file `code.o'.
File `code.o' does not exist.
Looking for an implicit rule for `code.o'.
Trying pattern rule with stem `code'.
Trying implicit prerequisite `code.c'.
Trying pattern rule with stem `code'.
Trying implicit prerequisite `code.cc'.
Trying pattern rule with stem `code'.
Trying implicit prerequisite `code.C'.
Trying pattern rule with stem `code'.
Trying implicit prerequisite `code.cpp'.
Found prerequisite `code.cpp' as VPATH `../Common/code.cpp'
Found an implicit rule for `code.o'.
Добавление -d в вызове из блока действий в узел-Gyp зависимой цели, тот же самый исходный файл получает это:
Considering target file `code.o'.
File `code.o' does not exist.
Looking for an implicit rule for `code.o'.
No implicit rule found for `code.o'.
Так это выглядит как неявные правила сборки подавляются (?)
Я вижу, что вы получаете, и чисто с точки зрения перспективы имеет смысл. – dtopham75
Я вижу, что вы получаете, и с точки зрения перспективы это имеет смысл. Однако, это не сработает. Проблема заключается в том, что node-gyp (или просто gyp) объединяет массив «action» вместе. Он не любит элементы, содержащие знак =. Это: «действие»: ["make", "-C", "/ path/to/makefile"] 'расширяется до' 'make -C/path/to/makefile' в сгенерированном make-файле для цель. Но «действие»: ["export MAKEFLAGS = -w && make -C", "/ path/to/makefile" ']' переходит в '"экспорт MAKEFLAGS = -w && make -C"/path/to/makefile ', без кавычек. То же самое для любого, содержащего a =. – dtopham75
@ dtopham75 Я должен был взять на себя труд, чтобы дать вам проверенное решение. Вот один из них: –