grobian
make depend is broken
make depend
complains
cannot find include file "bits/c++config.h"
...
not in /usr/include/x86_64-linux-gnu/bits/bits/c++config.h
...
The duplicate bits/bits looks like a bug.
On my Linux Mint system, that file is in
/usr/include/x86_64-linux-gnu/c++/10/bits/c++config.h
/usr/include/x86_64-linux-gnu/c++/7/bits/c++config.h
/usr/include/x86_64-linux-gnu/c++/9/bits/c++config.h
If the variable MAKEDEPEND_INCLUDES in the Makefile is changed from
-I/usr/include/x86_64-linux-gnu/c++/9/bits
to
-I/usr/include/x86_64-linux-gnu/c++/9
, the error goes away.
Likewise with asm/errno.h, changing
-I/usr/include/x86_64-linux-gnu/asm
to
-I/usr/include/x86_64-linux-gnu
With those two changes, it works properly.
However, the variable in the Makefile is generated by the configure script,
which is hand-written, and is evidently missing things.
(You mentioned before that it might be best to make a proper autoconf build.)
% echo "#include
should give you a list of includes that it believes it needs
I think this should be BS, since the compiler already knows these paths, so why make them explicit, no idea.
In my case it works out, because it includes the dir before bits:
-I/Users/fabian/Gentoo-11.0i/usr/lib/gcc/x86_64-apple-darwin20/11.2.0/include -I/Users/fabian/Gentoo-11.0i/usr/lib/gcc/x86_64-apple-darwin20/11.2.0/include-fixed -I/Users/fabian/Gentoo-11.0i/usr/lib/gcc/x86_64-apple-darwin20/11.2.0/include/g++-v11 -I/Users/fabian/Gentoo-11.0i/usr/lib/gcc/x86_64-apple-darwin20/11.2.0/include/g++-v11/backward -I/Users/fabian/Gentoo-11.0i/usr/lib/gcc/x86_64-apple-darwin20/11.2.0/include/g++-v11/bits -I/Users/fabian/Gentoo-11.0i/usr/lib/gcc/x86_64-apple-darwin20/11.2.0/include/g++-v11/debug -I/Users/fabian/Gentoo-11.0i/usr/lib/gcc/x86_64-apple-darwin20/11.2.0/include/g++-v11/ext -I/Users/fabian/Gentoo-11.0i/usr/lib/gcc/x86_64-apple-darwin20/11.2.0/include/g++-v11/pstl -I/Users/fabian/Gentoo-11.0i/usr/lib/gcc/x86_64-apple-darwin20/11.2.0/include/g++-v11/x86_64-apple-darwin20/bits
Let's see what happens when we don't do this magic.
hang on, makedepend is an external package, I don't even have it installed, is it worth bothering about this?
I think if we have missing deps, for the few files in the project, we better just add them manually.
Yeah. The make depend functionality is very helpful.
I remember using makedepend in the past.
I have no idea how the configure file was supposed to work, as I have never seen it working right.
The regex in your post (where you talk about magic) is incorrect. I can sort of fix that, but it doesn't make the configure file work right. I suspect this thing has been broken a long time.
I have continued to fiddle with this. I'll show you what I have.
Attached is a shell command for generating the makedepend includes.
I experimented with feeding it different C++ header files. Give it a try
The problem is, the generated list is always missing
-I/usr/include/x86_64-linux-gnu/
although the required header specified as bits/c++config.h is in fact in
/usr/include/x86_64-linux-gnu/bits/c++config.h
(the header is not in the directory /usr/include/c++/9/bits/)
Do we know why we need the header locations in the first place? What business do we have in toolchain land?
I don't pretend to understand how all this works.
I did try to get autoconf working.
The problem with that is, nothing is happy with the auto_ptr mess.
And the auto_ptr mess is just a bandage on top of a bandage on top of a bandage.
And then I wasted some time trying to just fix that mess. But there were a couple places where I couldn't tell what the author was trying to accomplish -- I'm afraid they got very confused themselves.
(The fact that operator new is disguised in function calls, and that they create auto_ptr, and promptly release its contents...etc.)
Right now, I'm back to thinking, it would be so much easier to just start with an HTML parser library.
For you, the main question is: will it build on the package maintainer's system?
Make depend is a functionality for developers, really.
Right, so this is a cost vs benefit thing. At the moment, it sort of "works". It needs a lot of investments to make it right. Benefit would be better maintenance/understanding. On the surface (for users) nothing much would change.
Yes, that would be my assessment. The main functionality is there, and much improved over previous releases.
The main thing is to make sure the build works for distro packagers, and that they are happy enough to do the work to push the package through. They might not even try "make depend".
this is now using autoconf (commit aa2541879a0e5b158650c152293c1c38b335dbc9)