|
I'm using linux mint 15. The "reference code" does not solve the problems with this demo, and there are plenty of people responsible for that. Diversity has a down side. :-) While the various locations of headers is admirable from the stand point of developers who can debug smaller collections of files, the maze created in trying to locate them is damned near unbearable for someone just trying to compile an example with that monstrosity of an IDE called Anjuta -- which ineffably does NOT use the pkg-config flags. So this is about Anjuta although the belated "comment" that the gstreamermm.h file should be included properly was not helpful. ;-) That reference is about halfway down the page. It should have been in the source example as well as the reference code, though that's at least "educational". Find: "While we are on it, also make sure that the gstreamermm.h is included in main.cc properly." You need to decide if that simple demo is for beginners or not. ;-) And that's it for the comment about the demo page that you do indeed have some control over. Now for the gritty.... And I'd like to get you on my side about this. Anjuta is the IDE recommended for the simple guitar tuner example at this page. I have now had to re-configure the build, probably 5 times, using pkg-config to find the possible locations for missing headers. The field for entering new paths is very restrictive (that could be a partial fix) so it is impractical to list ALL the pkg-config --cflags in that widget. Here's what I'm now inspired to show you. A piece of a screenshot.  I'm almost ready to give up on gstreamer in C++. 1. The problem is Anjuta. It is TOO BRAINY FOR ITS OWN GOOD. It reconfigures to my (already known) configuration every damned time I just add a new path to correct it's erroneous assumptions. 2. And now, where is gst/gstindex.h? It's in yet another place gstreamer hides its development headers. That suggests yet another "partial" fix. 3. Again, I apologize, and I understand the reasoning behind all the stuff tucked down under folders with version numbers, but if the idea is to make development possible for newbees, this is certainly not the tool for the job. So this pertains to "accessibility" for beginners. That is apparently your goal, and it's a good one, but there's a reason very few people use vi or vim anymore, right? 4. A much simpler editor and a better way to incorporate pkg-config information into an EDITABLE makefile would be far far more useful for beginners. This is NOT working, kids. If by some chance there is a standard somewhere, determining how/where symlinks should be applied for end users, this standard is not adequately published. I've had the same problem in open suse, kubuntu, and now mint linux. And in fact that standard should not even be necessary since pkg-config DOES know where to look for the headers. Autoconf, automake m4, and the rest of all that complicated nonsense does not. Think about it. A simple C/C++ file can be compiled from the commandline. We've come a long way, baby, but the trip may not be worth the gas. Simplify. Please. Feel free to forward this to anyone else who may have noticed this endemic problem in linux over the past decade or so, especially with Anjuta and just about every other IDE which seems unable to compile a simple C program without running configure on an already known system with paths hard coded into gcc. I use kdevelop from kde3 (just the binaries from suse 10). They (KDE4+) are wandering over the cliff too, with 50 megs of hidden files in your home directory for a C "hello world" console app. So if the "hot" linux programmers are somehow still using vi/vim, you KNOW something's wrong. And I suspect they are indeed using it. This newer crap is borderline unusable. Thanks for your time. -rs |