azinulbizar wrote:
In file included from TCommandLine.h:32:0,
from TConsole.h:37,
from TConsole.cpp:24:
Host.h:53:23: warning: extra tokens at end of #include directive
In file included from TLabel.h:25:0,
from TConsole.h:43,
from TConsole.cpp:24:
mudlet.h:48:23: fatal error: phonon: No such file or directory
compilation terminated.
make: *** [tmp/TConsole.o] Error 1
I realize the person I'm quoting worked around this, but I will explain (or at least elaborate. I imagine you already realize these facts, but just to be specific) this in a minute. Earlier today I was trying to compile this (on my fedora 17 box) and this is one of the issues I ran into. Of course, there were others including yajl (I assume the mudlet version is using a different API for yajl than what I have available). The reason I was looking to build this was two reasons:
1 - I was thinking of building an rpm for it.
2 - I've been working on a complete rewrite of a mud I've been the main programmer for, for years, and I wanted to play with this (I normally just use tintin++).
Anyway, the reason there is that error is because there's a conflict with the header file locations and the #include directive.
Three kinds of #include s in C and generally only two are used (in fact, of all the source I've ever looked at or worked on, I have never seen the third way that I recall. Considering it's a macro that expands and that itself is part of C I would guess that's why it's not used).
When the FILE (keyword) is between double quotes, it will search relative to the current directory.
When it (the file) is between angle brackets, it checks the default locations of the compiler. For instance:
$ echo 'int main() { return 0; }' > tmp.c ; gcc -v tmp.c
will show, among other things, this (where the first entry is arch-vendor-os specific):
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include
/usr/local/include
/usr/include
The third option is a computed directive by way of C macros.
Now, the phonon header files are in their own directory, much like many other libraries are. It is (as I mention below) possible that it was just one file before, but I sure do not know.
That means when a program has (in the above situation):
#include <phonon>
It won't include anything because that is a directory. Why does the error say 'mudlet.h:48:23: fatal error: phonon: No such file or directory' then ? That is the basic description of the errno ENOENT which is used for either or (remember in Unix and therefore Linux EVERYTHING is a file).
In Fedora 17 the current version of phonon-devel is 4.6.0 (release 3) and the files I found that need to be included (in mudlet.h):
phonon/phononnamespace.h
phonon/mediaobject.h
(each in brackets)
Note I did not finish compiling though and it seems that newer versions should not be used (I think I read that on this thread or somewhere on the site).
The only way it should work by just 'phonon' is if that is a file itself in the include directories. So I assume it is a version or packaging difference (maybe debian based distros do something different, as that's what mudlet is developed on ? I don't use either. I have only used debian itself and that was years ago). I find that a bit odd though because C header files in the system end with .h and C++ either have no extension (say, the C++ standard library headers) or some times .hxx or .hpp in the case of non-standard C++ libraries (possibly others as it's not a requirement). But as for why they got the error mentioned, it is most likely that. If they had a directory /usr/include/phonon (or /usr/local/include/phonon) then that would be why.
Perhaps this is more information than needed, but what I can I say/write? I am quite guilty of writing a lot.