Build process should have a way to do a clean build/full rebuild

[dcoshea]

The Git repository contains not only sources but also most or all of the binaries generated by running MAKEMOS.BAT. This means that when MAKEMOS.BAT is run from a clean Git repository, most targets are not rebuilt, because the source files and binaries will all have the same timestamps.

I believe that the reason some targets are still rebuilt is the renaming covered by issues #6 and #7 - SOURCES/src/mos5src/MAKEUTIL.MAK declares targets such as _286n.sys, but the Git repository contains the renamed version $286N.SYS instead, so make will actually generate that target (and the other ones that have _ or __ prefixes) every time it is run (except that issue #7 causes the subsequent build to fail due to the renaming affecting source files too).

The fact that some targets were being rebuilt initially made me think that everything was being built, but I later realised that there are other targets which aren't being rebuilt.

It would be nice if there was a simple way to either force everything to be rebuilt, or remove all of the generated output files as make clean does in many projects.

Adding -u options to the make command lines in MAKEMOS.BAT forces make to (attempt to) rebuild everything.

[galazwoj]

Please take a look a my fork of pcmos386. Since I have little knowledge of git I do not know how to say it better but to give an exact path to the file that has the relevant info
https://github.com/galazwoj/pcmos386v501/tree/master/SOURCES/compile-how-to.txt

I removed majority of *.bat files and rely on makefiles instead.

[stsp]

https://github.com/galazwoj/pcmos386v501/tree/master/SOURCES/compile-how-to.txt

You seem to be suggesting Borland make.
I tried Borland make from bc3.1 and got this
Fatal: Command arguments too long
when building MOS.
google reveals that this bug is present in
many versions of Borland's make, even
much newer than the one I used. Plus it
has different sources: PATH too long,
command line too long (in my case), etc.
So I would suggest against using borland
make if possible (or distribute the bug-free
version, which may be a license violation).
How about GNU make?

[galazwoj]

I use make from Borland C++ 4.5 with no problems but I modified some makefiles to avoid command line too long message which seems to be a limitation of command.com.
Sure I can try gnu make as well.

[stsp]

too long message which seems to be a limitation of command.com.

But when you build MOS with ms-make
then no such problem exist, otherwise no
one could ever built it. I tried both, with
same command.com, same makefile.
So I think its a borland's make problem.
If you already applied the work-around,
then maybe its fine for us to live with the
buggy make. :)
I hope this work-around does not involve
the temporary .lnk files as other projects
seem to be doing to avoid this problem.
In any case, considering the GNU make
may still be an advantage if you want
eventually move to the free toolchain.

[ghost]

Stale, out of date. Closing.