On 02/21/2011 08:29 PM, Kristopher Gamrat wrote:
On Mon, Feb 21, 2011 at 9:11 PM, David C. Rankin drankinatty@suddenlinkmail.com wrote:
<snip>
"More than happy sounds like a dangerous mental condition. 'We had to put Dave in the mental home... he was more than happy.'" --George Carlin
<snip>
I escaped ... :p
I think that's what Samelian was working on with that link. With just two devs (one of which doesn't know much about cmake), it could take awhile to get the "recipe" together. We also need to keep in mind that each package is going to have some specific options that won't work in all packages... some options might work in a few packages, or maybe just one, so the person doing each specific package would need to figure out those.
Yes, your 100% correct on the individual module specific needs. That's why I was thinking along the lines of a 'minimal cmake recipe' that you could then dig into the configure.in/(other files) for the individual modules and then plug it into the top-level CMakeLists.txt or in the CMakeLists.txt|cmake/modules/(whatever) files for the subdirs.
I'll go to trinity-desktop on freenode and see if I can get an answer to the question:
"If I were going to look at the cmake setup for an existing trinity module that I could use as a quasi-template to adapt to other modules that need to be ported --> Which existing Trinity module would provide a good reference to use?"
If I can get an answer to that, then I can feel confident that I'm looking in the right place.
It's kind of a twist on the old adage, "it doesn't matter how fast you can run -- if you're running in the wrong direction, you will never make it to the finish line" :)