22 Feb
2011
22 Feb
'11
2:57 a.m.
On 02/21/2011 08:29 PM, Kristopher Gamrat wrote:
On Mon, Feb 21, 2011 at 9:11 PM, David C. Rankin
<drankinatty(a)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" :)
--
David C. Rankin, J.D.,P.E.