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.
>>
>
>
