I always try to do things so that they fail either often or never. Sometimes I don’t care much which is the case—if they do fail often, it is easy to reproduce and I will fix it with less effort than an elusive bug.
“mkdir -p” is not resistant to human error of not calling it / not including the file that does it in one of ten scripts.
“mkdir -p” means that browsing the VCS history you do not see the real layout.
I bother with VCS-based solution when it works better (and my “better” includes estimated time to catch trivial mistakes and ease of looking up old history) than “mkdir -p”. Dynamic working directory layout is something I have yet to see often, so I do not discard better-for-me solutions because of reasons unapplicable to current project.
Human mistakes depend on workflow. Do you often accidentally remove your checkout? And human mistakes in initial setups should cause the failure as often as possible when they happen.
“mkdir -p” before each cd will make the scripts considerably longer for no sane reason. And I have a few places in this very deployment helper system where “mkdir -p” before cd will make the failure mode less convenient.
And yes, all that is writen in shell script and I do use “mkdir -p” in the code where it made sense for my task at hand.
Somehow, most buildsystems for complex packages run make with changing working directories. Even in single script using subshells, it is trivial to save some effort with changing directories without complicating the code.
It is a deployment helper, not a single-package build system, so it has to do some work with numerous checkouts of dependencies. It is more natural to write some parts of code to run inside working directories of individual packages.
I always try to do things so that they fail either often or never. Sometimes I don’t care much which is the case—if they do fail often, it is easy to reproduce and I will fix it with less effort than an elusive bug.
“mkdir -p” is not resistant to human error of not calling it / not including the file that does it in one of ten scripts.
“mkdir -p” means that browsing the VCS history you do not see the real layout.
I bother with VCS-based solution when it works better (and my “better” includes estimated time to catch trivial mistakes and ease of looking up old history) than “mkdir -p”. Dynamic working directory layout is something I have yet to see often, so I do not discard better-for-me solutions because of reasons unapplicable to current project.
Human mistakes depend on workflow. Do you often accidentally remove your checkout? And human mistakes in initial setups should cause the failure as often as possible when they happen.
“mkdir -p” before each cd will make the scripts considerably longer for no sane reason. And I have a few places in this very deployment helper system where “mkdir -p” before cd will make the failure mode less convenient.
And yes, all that is writen in shell script and I do use “mkdir -p” in the code where it made sense for my task at hand.
Why are you using
cdat all? You usemkdir -pbefore creating temporary files, and never randomlycd.Anyway, this thread isn’t really getting anywhere.
Somehow, most buildsystems for complex packages run make with changing working directories. Even in single script using subshells, it is trivial to save some effort with changing directories without complicating the code.
It is a deployment helper, not a single-package build system, so it has to do some work with numerous checkouts of dependencies. It is more natural to write some parts of code to run inside working directories of individual packages.