Organize the files in /john/src
Open
Nobody has claimed this yet.
enhancement
RFC / discussion
- Dominant language
- C
- Stars
- 13.6k
- Forks
- 2.6k
- PR merge metrics
- No merged PRs in 30d
Description
Well, thinking about this matter, I realized that a simple patch can solve the problem:
- I moved
*nt*formats and tested the patch; - it seems appropriate to me;
- I don't think it introduces new bugs;
- It would be very useful to organize the source tree;
- we can create a folder 'includes' and move non-
john_properheader files to it; - we can create modules like (e.g.): microsoft, sha1, sha2, coins, ...
Weak points:
- Makefile.legacy;
- is it portable as it should be?
What do you guys think? I need to sleep on this but I can't see any bad side effects.
diff --git a/src/configure.ac b/src/configure.ac
index 88d9e902b..4b05e2a6c 100644
--- a/src/configure.ac
+++ b/src/configure.ac
@@ -87,6 +87,9 @@ AC_ARG_ENABLE([fuzz], [AC_HELP_STRING([--enable-fuzz], [Fuzzing prepare(), valid
AC_ARG_ENABLE([libfuzzer], [AC_HELP_STRING([--enable-libfuzzer], [Fuzzing using libFuzzer])], [libfuzzer=$enableval], [libfuzzer=no])
dnl ===================== Actual tests start here ========================
+dnl Add the modules (folders inside src) and add the headers search path (includes) folder
+CPPFLAGS="-I$(pwd) $CPPFLAGS"
+MODULES=(" " "microsoft/")
dnl Assert that we don't have a stray GNUmakefile left in the tree :-(
if test -f GNU?akefile; then
@@ -1092,7 +1095,7 @@ else
AC_MSG_NOTICE([creating *_plug.c rules])
fi
if test "`echo *_plug.c`" != "*_plug.c"; then
- AC_SUBST([PLUGFORMATS_OBJS],[`echo *_plug.c | sed 's/opencl[[A-Za-z0-9_\-]]*\.c //g;s/\.c/.o/g'`])
+ AC_SUBST([PLUGFORMATS_OBJS],[`for i in "${MODULES[[@]]}"; do echo -n $i*_plug.c " "; done | sed 's/opencl[[A-Za-z0-9_\-]]*\.c //g;s/\.c/.o/g'`])
AC_SUBST([OPENCL_PLUGFORMATS_OBJS],[`echo opencl*_plug.c | sed 's/\.c/.o/g'`])
if test "x$plug_deps" = xyes -a "x$PERL" != x ; then
AC_MSG_NOTICE([creating Makefile dependencies])
@@ -1137,7 +1140,9 @@ if test "x$simd" = xno ; then
fi
if test "`echo *_fmt_plug.c`" != "*_fmt_plug.c"; then
- $CPP -P -DAC_BUILT $CFLAGS_EX2 $CPPFLAGS $CPU_BEST_FLAGS $CFLAGS $HAVE_OPENCL $CFLAGS_EXTRA $OPENMP_CFLAGS $OPENSSL_CFLAGS -DFMT_EXTERNS_H *_fmt_plug.c | LC_ALL=C $GREP "extern struct fmt_main" | LC_ALL=C $SORT -f > fmt_externs.h
+ for i in "${MODULES[[@]]}"; do
+ $CPP -P -DAC_BUILT $CFLAGS_EX2 $CPPFLAGS $CPU_BEST_FLAGS $CFLAGS $HAVE_OPENCL $CFLAGS_EXTRA $OPENMP_CFLAGS $OPENSSL_CFLAGS -DFMT_EXTERNS_H $i*_fmt_plug.c | LC_ALL=C $GREP "extern struct fmt_main" | LC_ALL=C $SORT -f >> fmt_externs.h
+ done
fi
dnl if the file was not created, then bail.
if test -f fmt_externs.h -a ! -s fmt_externs.h; then
@@ -1151,7 +1156,9 @@ fi
AC_MSG_NOTICE([creating ./fmt_registers.h])
rm -f fmt_registers.h
if test "`echo *_fmt_plug.c`" != "*_fmt_plug.c"; then
- $CPP -P -DAC_BUILT $CFLAGS_EX2 $CPPFLAGS $CPU_BEST_FLAGS $CFLAGS $CFLAGS_EXTRA $OPENMP_CFLAGS $OPENSSL_CFLAGS -DFMT_REGISTERS_H *_fmt_plug.c | LC_ALL=C $GREP "john_register_one" | LC_ALL=C $SORT -f > fmt_registers.h
+ for i in "${MODULES[[@]]}"; do
+ $CPP -P -DAC_BUILT $CFLAGS_EX2 $CPPFLAGS $CPU_BEST_FLAGS $CFLAGS $CFLAGS_EXTRA $OPENMP_CFLAGS $OPENSSL_CFLAGS -DFMT_REGISTERS_H $i*_fmt_plug.c | LC_ALL=C $GREP "john_register_one" | LC_ALL=C $SORT -f >> fmt_registers.h
+ done
fi
dnl if the file was not created, then bail.
if test -f fmt_registers.h -a ! -s fmt_registers.h; then
--
2.39.2
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review src/configure.ac and the Makefile.legacy portability concern first, then map the proposed includes and module layout against the current /john/src tree. Done means the source files are organized as agreed while generated registrations and builds remain portable across the supported configurations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, shell
- Domain
- build-system, tooling
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100