On 10/14/2011 12:58 AM, Rolf Eike Beer wrote:
> Am Donnerstag, 13. Oktober 2011, 20:09:04 schrieb Michael Hertling:
>> On 10/12/2011 03:40 PM, Rolf Eike Beer wrote:
On 10/03/2011 09:18 AM, Yuri Timenkov wrote:
> Hi Michael,
>
> On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling
>
Am Donnerstag, 13. Oktober 2011, 20:09:04 schrieb Michael Hertling:
> On 10/12/2011 03:40 PM, Rolf Eike Beer wrote:
> >> On 10/03/2011 09:18 AM, Yuri Timenkov wrote:
> >>> Hi Michael,
> >>>
> >>> On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling
> >>>
> >>> wrote:
> On 10/01/2011 10:07 AM, Yu
On 10/13/2011 08:26 AM, Yuri Timenkov wrote:
> See my comments inline.
>
> I could make an implementation proposal, but I don't have time till the end
> of November. So this discussion is quite pointless.
>
> On Wed, Oct 12, 2011 at 3:02 PM, Michael Hertling wrote:
>
>> On 10/03/2011 09:18 AM, Y
On 10/12/2011 03:40 PM, Rolf Eike Beer wrote:
>> On 10/03/2011 09:18 AM, Yuri Timenkov wrote:
>>> Hi Michael,
>>>
>>> On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling
>>> wrote:
>>>
On 10/01/2011 10:07 AM, Yuri Timenkov wrote:
> that's the problem: you don't know neither file name nor it's
> On 10/03/2011 09:18 AM, Yuri Timenkov wrote:
>> Hi Michael,
>>
>> On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling
>> wrote:
>>
>>> On 10/01/2011 10:07 AM, Yuri Timenkov wrote:
that's the problem: you don't know neither file name nor it's
location,
especially in multi-configuration
On 10/03/2011 09:18 AM, Yuri Timenkov wrote:
> Hi Michael,
>
> On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling wrote:
>
>> On 10/01/2011 10:07 AM, Yuri Timenkov wrote:
>>> that's the problem: you don't know neither file name nor it's location,
>>> especially in multi-configuration generators.
>>
Hi Michael,
On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling wrote:
> On 10/01/2011 10:07 AM, Yuri Timenkov wrote:
> > that's the problem: you don't know neither file name nor it's location,
> > especially in multi-configuration generators.
>
> You *do* know a debug file's name and location, eith
On 10/01/2011 10:07 AM, Yuri Timenkov wrote:
> that's the problem: you don't know neither file name nor it's location,
> especially in multi-configuration generators.
You *do* know a debug file's name and location, either because you must
generate it explicitly (objcopy approach) or via the concer
On 10/01/2011 01:35 PM, Rolf Eike Beer wrote:
> Am Samstag 01 Oktober 2011, 06:11:44 schrieb Michael Hertling:
>> On 09/30/2011 08:39 AM, Rolf Eike Beer wrote:
On 09/29/2011 06:15 AM, Yuri Timenkov wrote:
> When I was investigating similar problem, I found alternative
> approach
>
Am Samstag 01 Oktober 2011, 06:11:44 schrieb Michael Hertling:
> On 09/30/2011 08:39 AM, Rolf Eike Beer wrote:
> >> On 09/29/2011 06:15 AM, Yuri Timenkov wrote:
> >>> When I was investigating similar problem, I found alternative
> >>> approach
> >>> at
> >>> http://code.google.com/p/dynamorio/sourc
that's the problem: you don't know neither file name nor it's location,
especially in multi-configuration generators.
It's also bad idea to mix build and install steps. Install command doesn't
understand generators expressions.
If it were possible to emulate vs behavior for gcc things would be muc
On 09/30/2011 08:39 AM, Rolf Eike Beer wrote:
>> On 09/29/2011 06:15 AM, Yuri Timenkov wrote:
>>> When I was investigating similar problem, I found alternative approach
>>> at
>>> http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.txt.
>>>
>>> The thing is to change linker rules, to
> On 09/29/2011 06:15 AM, Yuri Timenkov wrote:
>> When I was investigating similar problem, I found alternative approach
>> at
>> http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.txt.
>>
>> The thing is to change linker rules, to something like this:
>> set(CMAKE_C_CREATE_SHARE
On 09/29/2011 06:15 AM, Yuri Timenkov wrote:
> When I was investigating similar problem, I found alternative approach at
> http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.txt.
>
> The thing is to change linker rules, to something like this:
> set(CMAKE_C_CREATE_SHARED_LIBRARY
When I was investigating similar problem, I found alternative approach at
http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.txt.
The thing is to change linker rules, to something like this:
set(CMAKE_C_CREATE_SHARED_LIBRARY
# standard rule
"
-o
"
On 09/22/2011 01:24 PM, Rolf Eike Beer wrote:
>> Il 22/09/2011 10.13, Rolf Eike Beer ha scritto:
Yeah, that's exactly what I had in mind. Any chance that we will see
this in a future release?
>>> This is usually "find someone who does it and writes tests for it".
>>> Which
>>> then boils
> Il 22/09/2011 10.13, Rolf Eike Beer ha scritto:
>>> Yeah, that's exactly what I had in mind. Any chance that we will see
>>> this in a future release?
>> This is usually "find someone who does it and writes tests for it".
>> Which
>> then boils down to find someone who has enough knowledge and sp
Il 22/09/2011 10.13, Rolf Eike Beer ha scritto:
Yeah, that's exactly what I had in mind. Any chance that we will see
this in a future release?
This is usually "find someone who does it and writes tests for it". Which
then boils down to find someone who has enough knowledge and spare time to
do o
> Yeah, that's exactly what I had in mind. Any chance that we will see
> this in a future release?
This is usually "find someone who does it and writes tests for it". Which
then boils down to find someone who has enough knowledge and spare time to
do or someone that needs it and is willing to pay
Yeah, that's exactly what I had in mind. Any chance that we will see
this in a future release?
Meanwhile I will try to find a clean way to run objdump out of CMake manually.
On Thu, Sep 22, 2011 at 09:37, Rolf Eike Beer wrote:
> Sadly not. This is also annoying for e.g. MSVC builds where the deb
20 matches
Mail list logo
