I've got a makefile (developed for gmake
on Linux) that I'm attempting to port to MacOS, but it seems like sed
doesn't want to cooperate. What I do is use GCC
to autogenerate dependency files, and then tweak them a bit using sed
. The relevant portion of the makefile
:
$(OBJ_DIR)/%.d: $(SRC_DIR)/%.cpp
$(CPPC) -MM -MD $< -o $@
sed -i 's|\(.*\)\.o:|$(OBJ_DIR)/\1.o $(OBJ_DIR)/\1.d $(TEST_OBJ_DIR)/\1_utest.o:|' $@
While this runs with no trouble under GNU/Linux, I get errors like the following when attempting to build on MacOS:
sed: 1: "test/obj/equipmentConta ...": undefined label 'est/obj/equipmentContainer_utest.d'
sed: 1: "test/obj/dice_utest.d": undefined label 'est/obj/dice_utest.d'
sed: 1: "test/obj/color-string_u ...": undefined label 'est/obj/color-string_utest.d'
It would seem like sed
is chopping off a character, but I can't see the solution.
OS X
sed
handles the-i
argument differently to the Linux version.You can generate a command that might "work" for both by adding
-e
in this way:OS X
sed -i
interprets the next thing after the-i
as a file extension for a backup copy of the in-place edit. (The Linux version only does this if there is no space between the-i
and the extension.) Obviously a side affect of using this is that you will get a backup file with-e
as an extension, which you may not want. Please refer to other answers to this question for more details, and cleaner approaches that can be used instead.The behaviour you see is because OS X
sed
consumes thes|||
as the extension (!) then interprets the next argument as a command - in this case it begins witht
, whichsed
recognizes as a branch-to-label command expecting the target label as an argument - hence the error you see.If you create a file
test
you can reproduce the error: