Summary: | New Project Makefile.am names non-existent file | ||
---|---|---|---|
Product: | [Applications] kdevelop | Reporter: | Ian Wadham <iandw.au> |
Component: | Build tools: Automake | Assignee: | KDevelop Developers <kdevelop-devel> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 3.0.0a7 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Ian Wadham
2003-10-02 11:00:56 UTC
"myappiface.h" is a description of the DCOP interface to "myapp". This is the file you typically write yourself when you want a DCOP interface. The myappIface.h file is turned into an XML description (myappiface.kidl), which in turn is turned into C++ code (the myapp_skel.cpp file) which is the actual DCOP interface implementation but you never really need to know about. (Start 'myapp' and 'kdcop' and you'll find the myappIface interface with the openURL() method that you can call from another program - this is the purpose of the myapp_client program that is also built with this template) The DCOP interface is of course safe to remove, if you remove all references to it in the code (The myappView class inherits myappIface, for instance) See also the template README file. There is a bug here, however. As you pointed out myapp.skel is shown in the automake manager. This isn't a file at all, it is just a way to tell the KDE build system to generate the DCOP stuff. It should be filtered out from automake manager. ... or maybe not. I implemented a simple hiding of .skel files from the automake manager listing, but before committing it was pointed out to me by Ian Geiser that this would remove the functionality of removing this build system marker without editing of the makefile.am file. So.. I'm going with WONTFIX. Yes, it is confusing and there is no currenly way of _adding_ the DCOP interface marker through the automake gui, except adding a real file with the matching name (the content of which is without meaning, only the name matters). I suspect a real fix for this issue, whatever shape it takes, won't be in place before KDevelop-3.1 |