>> Builds rtt with Macports on Leopard 10.5.2 on Intel iMac, bar one of the test
>> cases, generictask_test_3. I'm not sure if this is a compiler bug, or just the
>> result of a more strict compiler (Leopard is "i686-apple-darwin9-gcc-4.0.1
>> (GCC) 4.0.1 (Apple Inc. build 5465)". I have included a notational workaround
>> within this file, but it is ugly to say the least. This type of problem seen
>> before, see
>>
>> http://gcc.gnu.org/ml/gcc-bugs/2005-03/msg01211.html
>> http://www.megasolutions.net/cplus/Copy-construction-with-inaccessible-base-class-copy-c-tor-20108.aspx
>>
>> Still needs a complete rewrite of semaphore implementation.
>>
>
>Nice work. Did it pass all the unit tests ?
>
>Peter
All tests build except for "taskcontext_test" which has the compiler error with "generictask_test_3" (as mentioned above) .
core-test and dev-test run successfully.
All other built tests fail on the semaphore library with something like
0.002 [CRITICAL][PeriodicThread] Could not allocate configuration semaphore 'sem' for
Basically, we need to write a semaphore implementation. Can probably lift most of one from something online use a mutex and condition variable. Don't remember the last place I saw one ... but I know I've seen them before ...
S
[Bug 533] Mac OS X port
On Thu, 17 Jul 2008, Stephen Roderick wrote:
> On Jul 17, 2008, at 08:40 , Klaas Gadeyne wrote:
>>>>> Side issue - we need to use a consistent method of adding
>>>>> package-related paths to statements like FIND_PATH and FIND_LIBRARY.
>>>>
>>>> Do you refer to the NO_DEFAULT_PATH statements here?
>>>
>>> No. I had to hardwire in the default MacPorts path to the FIND_XXX calls.
>>> Notice that the Fink paths aren't there (wonder how this works for you?).
>>> I was
>>> just getting at the fact that probably should centralise this list of
>>> "non-standard paths". Originally we had a cmake variable deciding between
>>> Fink
>>> and MacPorts, and then used that to generate the non-standard path of
>>> choice.
>>> Either something like that, or maybe as simple as just add global cmake
>>> var's
>>> that hold a list of non-standard include and lib dirs to use in FIND_XXX
>>> calls.
>>> That way, only one place has to change if we need to add/modify the list.
>>>
>>> Thoughts?
>>
>> Yes, see
>> We shouldn't try to look everywhere. That results into disaster
>> (especially when cross-compiling). It's up to the user to specify those
>> non-standard locations via CMAKE_INCLUDE_PATH etc., and the FIND_XXX calls
>> take into account these. So maybe your patch wasn't even necessary?
>
> I tried the CMAKE_INCLUDE_PATH, and it didn't work for me. :-(
Hmm, really weird, since I tested this already on linux to for something I moved to a non-standard location. Could it be that there was some issue with the cmake cache or that you made a typo?
Klaas
[Bug 533] Mac OS X port
On Thursday, July 17, 2008, at 09:09AM, "Klaas Gadeyne" <klaas [dot] gadeyne [..] ...> wrote:
>On Thu, 17 Jul 2008, Stephen Roderick wrote:
>> On Jul 17, 2008, at 08:40 , Klaas Gadeyne wrote:
>>>>>> Side issue - we need to use a consistent method of adding
>>>>>> package-related paths to statements like FIND_PATH and FIND_LIBRARY.
>>>>>
>>>>> Do you refer to the NO_DEFAULT_PATH statements here?
>>>>
>>>> No. I had to hardwire in the default MacPorts path to the FIND_XXX calls.
>>>> Notice that the Fink paths aren't there (wonder how this works for you?).
>>>> I was
>>>> just getting at the fact that probably should centralise this list of
>>>> "non-standard paths". Originally we had a cmake variable deciding between
>>>> Fink
>>>> and MacPorts, and then used that to generate the non-standard path of
>>>> choice.
>>>> Either something like that, or maybe as simple as just add global cmake
>>>> var's
>>>> that hold a list of non-standard include and lib dirs to use in FIND_XXX
>>>> calls.
>>>> That way, only one place has to change if we need to add/modify the list.
>>>>
>>>> Thoughts?
>>>
>>> Yes, see
>>> We shouldn't try to look everywhere. That results into disaster
>>> (especially when cross-compiling). It's up to the user to specify those
>>> non-standard locations via CMAKE_INCLUDE_PATH etc., and the FIND_XXX calls
>>> take into account these. So maybe your patch wasn't even necessary?
>>
>> I tried the CMAKE_INCLUDE_PATH, and it didn't work for me. :-(
>
>Hmm, really weird, since I tested this already on linux to for something I moved to a non-standard location. Could it be that there was some issue with the cmake cache or that you made a typo?
Certainly possible. I will try again soon just to make sure.
S
[Bug 533] Mac OS X port
On Wednesday 20 August 2008 13:46:37 S Roderick wrote:
> >
> > It's a bug in the compiler, it's valid C++.
>
> Ok, but is that part of the patch acceptable?
If it needs to be done, it needs to be done :-). The patch is *also* valid C++
so it is acceptable...
Peter