Robert- I wanted to craft a witty retort with a veneer of encouragement that might push your towards trying your proposed endeavor. I could not bring myself to do it after realizing that you are quite serious. I understand your motivations. Build systems are often complicated, opaque pieces of software with many bespoke elements, like syntax, configuration, and macro systems. They often become that way because software projects of any large size start to take on their own arbitrary conventions and requirements that must be handled. We just love to shoot ourselves in the foot.
I feel like these are self evident, but perhaps there is a grok gap I'm not seeing. Bash is a shell, a language and an old friend. It is not a build system. Narrowing and/or expanding a piece of software's scope to address problems it isn't concerned with is almost always going to end in tears. See the Unix Philosophy <https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well>: do one thing and do it well. I recommend you attempt this endeavor independently, as a learning experience. Try writing a script and a function library that will allow you to build the Bash project (or something simpler) without Make or Autotools. You will come to understand why the world is as it is. You will come to truly comprehend the dark side of dealing with compilation caches, diverse compiler output, job control, dependency management, packaging, and all the other painful things. After that exercise, take a look at some of approaches people have taken. CMake, Maven, Gradle, and SCons are good projects to look at. Just take a look at how much thought went into Maven's Dependency Version Requirement Specification <https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification>. There is no magic that will lead to the 'Perfect Build System'. It takes well thought out architecture, obsession with details, and a gobs of effort. Even with all that, it will never be perfect or universal. There is always a use case or edge case you didn't deal with. I hope this response was of benefit to you. Dave Finlay On Fri, Dec 2, 2016 at 2:29 AM, Robert Durkacz <robert.durk...@gmail.com> wrote: > I agree that is the first step to take, but I am supposing that, since > build systems are a big business, some extensions to bash would be worth > doing to take on that market. E.g. I think we would need a concept of lists > of files so as to skip executing a command if all files in the list are > older than some file that is required. > > On 29 November 2016 at 02:21, Dennis Williamson < > dennistwilliam...@gmail.com> wrote: > >> >> >> On Sun, Nov 27, 2016 at 7:25 PM, Robert Durkacz <robert.durk...@gmail.com >> > wrote: >> >>> Has thought been given, over the years, to extending bash to do >>> what make does, in the obvious way that I am about to describe? >>> >>> It would be a matter of having chosen build commands do nothing if their >>> outputs are newer than their inputs. For example that is, cc file.c -o >>> file.o should execute normally if file.c is the newer file but do nothing >>> if file.o is newer. >>> >>> Then you would have a deterministic script to build a system that simply >>> skipped steps determined to be unnecessary. >>> >>> It is possible to achieve this without changing bash but it seems like >>> there would be leverage in having bash deliberately support this mode. >>> >> >> >> Use the newer-than test: >> >> source=file.c >> object=file.o >> [[ $source -nt $object ]] && cc "$source" -o "$object" >> >> >> -- >> Visit serverfault.com to get your system administration questions >> answered. >> > >
