Quite true.
I suspect that the way the C programming language handles "packages" can't
be made any simpler than it already is. The library headers are stored
somewhere (anywhere) in the file system, and so are the object files, if
there are any. Then, to be able to build our software with them, we only
need to configure the compiler to search for those header and object files
where we left them.
I suspect that this is only an issue when automatic build systems make this
to be harder than it is, and needs to be.
well, it is a little nicer on Linux than it is on Windows (especially if
using MSVC), but even then, on Windows headers and libraries are found
via environment variables ("Include" and "LIB" or similar).
MS sets them up via a brain-dead batch-file.
and it is fairly problematic, say, to be able to interface MSVC (or even
Visual Studio) with the DirectX SDK (vs it being more automatic, like
what would be expected from MS).
most applications and libraries, similarly, also tend to have their own
directories for headers, libraries, and binaries (typically installed
somewhere under "C:\Program Files" or "C:\Program Files (x86)", but
sometimes things like "%HOMEPATH%\AppData\..." or similar).
so, typically this may mean things like creating new batch files, which
include other stuff in the various environment variables (such as by
chaining to the old batch files and adding new stuff afterwards).
however, there are merits to the Windows strategy as well.
on Linux, there is another problem:
it is problematic to store libraries somewhere not part of the standard
OS paths. so, it goes to the extreme in the opposite direction.
maybe some sort of "library registry" could make sense, with libraries
registering themselves with the OS or compiler or similar.
maybe, a compiler extension for "do I have X?" could also make sense:
#define MYAPP_USE_GTK _HAS_LIBRARY("gtk")
in addition maybe to something to indicate to link-in libraries from
within headers and source-files:
__use_library__("gtk");
which could (probably) largely eliminate the need for auto-configuration
and manually specifying libraries as command-line options.
other more speculative options are also possible (like if functionality
currently handled by "make" were integrated into the compiler, ...).
hmm (foo_main.c):
<--
#include <stdio.h>
#ifdef _BAR_CC_
__use_file__(
"base/foo_a.c",
"base/foo_b.c",
"base/foo_c.c");
__use_library__(
"somelib1", "somelib2");
....
#endif
int main()
{ ... }
-->
likewise, the compiler could also use and invoke external tools, ...
then, the compiler is invoked something like: "barcc foo_main.c", and
itself proceeds to build the whole rest of the project.
or such...
