Open C0deH4cker opened 1 year ago
As an aside, I think it would be nice for pwnmake
or pwnmake .
to build the current directory's project, but pwnmake all
would still build all projects. This means that the .
target would now be the default target in PwnableHarness's Makefile
, and it would delegate to either all
or all[project]
if PWNMAKE_CWD
is defined.
It's common for CTFs to be organized in a repo with a bunch of challenges in the subdirectories. As an example, check out SunshineCTF 2022.
I would like to be able to run a command like
pwnmake docker-start
from within thePwn/CTFSim
directory (for example), and have it act likepwnmake docker-start[ctfsim]
from the root of that repo clone. That is, build products will go in the top-level.build
directory, files will be published to the top-levelpublish
directory, any parentBuild.mk
orAfter.mk
files will still be parsed (so they can define variables that are used by CTFSim'sBuild.mk
), and anyprebuild.sh
scripts are applied to the pwnmake environment. So effectively, when thepwnmake
command is run, each directory from the current directory upwards will be checked until the pwnmake workspace marker file is found.Perhaps this file will be called
.pwnmake
and just needs to exist. Or maybe its content can be useful? Maybe the existingprebuild.sh
file can be namedpwnmake-workspace.sh
or something, so if an upwards directory search for that file finds a result, that directory will be considered the pwnmake root. Thepwnmake
script would then need to pass some variable tomake
to set the current directory, perhapsPWNMAKE_CURRENT_DIRECTORY
orPWNMAKE_CWD
. The various makefile targets likedocker-start
and evenall
will need to respect that variable in filtering down which specific rules the top-level targets list as dependencies.