There are two reasons for removing this dependency:
- If someone does 'make avail' on the top level Makefile he ends up with
binaries but without libraries - not nice. Better do just "nothing" and
have hin understand that he needs to do 'make [all]' on the top level
Makfile first.
- If 'make avail' is done via 'sudo' it isn't desirable to do a large amount
of work as root.
BTW: I wasn't sure if this dependency is a good thing in the first place
but I saw it in many examples ('install' depending on 'all') so I did it too.
The [un]install make goals have a rather fixed meaning for *ix users. The simple
symlinks provided here don't match the expectations users have from [un]install.
Therefore it is appropriate to rename them to "something" not tied to specific
expectations.
There's a quite special case of a targetutil for the TARGET geos-apple having to be
built as TARGET apple2enh binary. We can't just add a dependency to ../lib/apple2enhlib
because the TARGETs are built in individual make instances (because of vpath).
Doing that the "right way" would be _very_ complicated and would turn the Makefiles way
less readable. Therefore I decided to solve that by just reordering the TARGETs. Surely
this won't work if i.e. 'make geos-apple' is entered on a clean system. But still I consider
it appropriate.
I ordered the TARGETs btw so that they are more in an alphabetical order...
Now that we're pretty much independent from CC65_HOME
it doesn't make sense anymore to look for it in the Makefiles.
So rather dynamically check if there are "local" binaries in the
../bin directory. If there are "local" binaries use them - and
otherwise rely on "installed" binaries found in the path.
While ca65, cc65 and ld65 have built-in paths cl65 doesn't.
That means that up to now cl65 depended on the binaries
being found in the path env var. However it makes sense
to presume that the binaries are located in the very same
directory cl65 is located in. So whatever pathname was
suitable to run cl65 should be suitable to run the other
binaries too. But if for some reason there's no valid
argv[0] or if it doesn't contain at least one directory
delimiter ('/' or '\') then fall back to relying on the
path env var.
In contrast to *IX it doesn't make much sense to add compile time defined
search paths to Windows binaries: There's no standard path like /usr/local/bin
(and there are no symbolic links to link from there to another location).
On the other hand it's (again in contrast to *IX) easy for Windows binaries
to determine their own paths. Therefore it's appropriate to make use of that
to add run time defined default search paths.
- No complex shell logic.
- "Source file shadowing" for all targets via vpath.
- Dependency handling.
- True incremental build.
- Don't write into source directories.
- Easy cleanup by just removing 'wrk'.
- No complex shell logic.
- "Source file shadowing" for all targets via vpath.
- Dependency handling.
- True incremental build.
- Don't write into source directories.
- Easy cleanup by just removing 'wrk'.
