On Thu, Jun 19, 2014 at 4:54 AM, David Rowe <[email protected]> wrote:
> 1/ Is it possible to make fdmdv2-dev build codec-dev and fdmdv2 build
> with codec2 automatically? Or easier just to have specific
> cmake/BuildCodec2.cmake files for both?
>
I may have to think about this one... We may be able to add some logic to
the existing BuildCodec2.cmake. We would have to find a way to detect if we
were building fdmdv2 or fdmdv2-dev and then choose the appropriate svn
location based on that.
> 2/ We should consolidate down to one README, not sure if there is
> anything of value in the other READMEs any more, but we should check.
> Also (to all) I'm not sure how OSX & FreeBSD are handled? Would be nice
> to have concise build instructions for these too, if not already there.
>
Agreed, I just didn't think I was the right person to decide what should
stay and what should go :)
It looks like most of your old README.linux can be salvaged by just
replacing the building part with my cmake README and some general clean up.
I think we should move your README.txt to just README since there's not
much point in having a zero length README.
3/ Would it be worthwhile setting the default build to do a static
> wXWidgets, codec2-dev, and portaudio? These are the biggest gotchas.
> For me having builds work first time is more important possible
> efficiencies. Or we could at least document the cmake command line for
> this really common case in README.cmake
>
I'm a distro packager at heart and I have a hard time thinking of doing
static by default but you could probably twist my arm :)
I'd prefer to see how to make doing the static builds easier. We could add
logic to the cmake build that if it doesn't find a compatible system
library to automatically switch over to doing a static build.
> 4/ If I edit a CMakeLists.txt file, how do I re-run cmake so it's picks
> up any changes? Only thing I can do ATM is rm build_linux but that
> wastes a lot of time if I'm using static wxWidgets.
It should pick up the changes fine, I usually clean everything out to be
safe but in most cases that's overkill. Just keep in mind there may be some
types of changes (corner cases) where it won't work as expected.
Thanks,
Richard
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
