Support all of Make CLI arguments

[casperdcl]

• -b, -m Ignored for compatibility.
• -B, --always-make Unconditionally make all targets.
• -C DIRECTORY, --directory=DIRECTORY
  Change to DIRECTORY before doing anything.
• -d Print lots of debugging information.
• --debug[=FLAGS] Print various types of debugging information.
• -e, --environment-overrides
  Environment variables override makefiles.
• -f FILE, --file=FILE, --makefile=FILE
  Read FILE as a makefile.
• -h, --help Print this message and exit.
• -i, --ignore-errors Ignore errors from commands.
• -I DIRECTORY, --include-dir=DIRECTORY
  Search DIRECTORY for included makefiles.
• -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with no arg.
• -k, --keep-going Keep going when some targets can't be made.
• -l [N], --load-average[=N], --max-load[=N]
  Don't start multiple jobs unless load is below N.
• -L, --check-symlink-times Use the latest mtime between symlinks and target.
• -n, --just-print, --dry-run, --recon
  Don't actually run any commands; just print them.
• -o FILE, --old-file=FILE, --assume-old=FILE
  Consider FILE to be very old and don't remake it.
• -p, --print-data-base Print make's internal database.
• -q, --question Run no commands; exit status says if up to date.
• -r, --no-builtin-rules Disable the built-in implicit rules.
• -R, --no-builtin-variables Disable the built-in variable settings.
• -s, --silent, --quiet Don't echo commands.
• -S, --no-keep-going, --stop
  Turns off -k.
• -t, --touch Touch targets instead of remaking them.
• -v, --version Print the version number of make and exit.
• -w, --print-directory Print the current directory.
• --no-print-directory Turn off -w, even if it was turned on implicitly.
• -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE
  Consider FILE to be infinitely new.
• --warn-undefined-variables Warn when an undefined variable is referenced.

[casperdcl]

Hello @lrq3000 from tqdm/tqdm#290

[lrq3000]

Oh wow, this is a great deal more ambitious than what I initially
envisioned lol

[casperdcl]

yeah I don't want to work out the true number of C libraries that a full make system will really need. no way I'd even expect even half of these to be implemented here. but it's nice to track progress.

[lrq3000]

Great @casperdcl , you're right, that's great to track progress, thank's for making this list.

I would like to add that I think this might become part of native python because there is a serious need : everybody make scripts to build their software, and pythonists usually use a bunch of bash scripts instead of python scripts because it's not straightforward to do commandline calls using Python, at least not as much as bash.

With this library, it will be easy to make pure python recipes calling both external commands and python commands.

[casperdcl]

Hey @lrq3000 just saw you re-implemented some docopt features in branch py2-shlex-madness... Perhaps you're using an outdated version? I've now specified docopt>=0.6, could you try installing from master and testing now?

[lrq3000]

I installed the last one docopt v0.6.2, it's really just shlex that is
failing harshly in py2.6...

2016-10-30 22:28 GMT+01:00 Casper da Costa-Luis [email protected]:

Hey @lrq3000 https://github.com/lrq3000 just saw you re-implemented
some docopt features in py-make/py2-shlex-madness... Perhaps you're using
an outdated version of docopt? I've now specified docopt>=0.6, could you
try installing from master and testing now?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABES3rj1CCgHedytVUX1cSljt7kSS_Keks5q5QwCgaJpZM4Kjz_1
.

[casperdcl]

@jonathanslenders, a bit cheeky to request this - but since we've pulled in a lot of users for jonathanslenders/ptpython by using it on our home page tqdm/tqdm and you've done things like pyvim, pymux, maybe you'd like to help or have some suggestions on how to go about doing this?

For example, I'm not sure if it's easier to first implement an early version of Make by going through some old code line-by-line, or just try and implement features one-by-one as and when...

[jonathanslenders]

Hi @casperdcl,

I'm not sure that pymux or pyvim can be compared with Make, but for what it's worth, I never had a look at the Vim source code. I went through parts of the tmux source code, but it was definitely not a literal translation. In Python, we have usually a very different approach of coding.

I'd suggest the following:

• Make sure to understand all of Make as good as possible.
• Solve one problem at a time. Make sure to have unit tests for this.
• Go to the next problem, refactor, and so on.

It sounds like an ambitious project!

edit: Oh - and don't underestimate these projects. I did underestimate the functionality of GNU Readline. But still, it can be fun!

[casperdcl]

Thanks @jonathanslenders - it helps to know that looking at all of make's source isn't necessary.