incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Bauer <mathias.ba...@numberfour.eu>
Subject Re: Help! JunitTest_framework_unoapi.mk:28: *** Malformed target-specific variable definition. Stop.
Date Tue, 20 Dec 2011 14:12:47 GMT
Hi,

sorry, but I don't have the Windows machine anymore where I did my OOo 
builds. Nowadays I'm only building on Linux. But you can follow my build 
instructions for make in the OOo wiki: just download the 3.81 source 
tarball, unpack it, configure, apply the patch and build.

Regards,
Mathias

On 20.12.2011 02:38, Zhe Liu wrote:
> Thank you for the comment.
> Could you share your make?  Juergen said that he can provide space to store it.
> I prefer to directly use it. -:)
>
> 2011/12/20 Mathias Bauer<Mathias_Bauer@gmx.net>:
>> On 19.12.2011 23:23, Andrew Rist wrote:
>>>
>>>
>>>
>>> On 12/16/2011 9:24 AM, Mathias Bauer wrote:
>>>>
>>>> On 16.12.2011 03:43, Zhe Liu wrote:
>>>>>
>>>>> Hi All,
>>>>> I always break because of the error when build on Windows XP. I
>>>>> mentioned before, nobody responsed on it. I did a little search and
>>>>> found someone also encountered the problem. I still have no clue how
>>>>> to resolve it.
>>>>>
>>>>> JunitTest_framework_unoapi.mk:28: *** Malformed target-specific
>>>>> variable definition. Stop.
>>>>>
>>>>> To continue my build, I have to remove the lines related to Junitest.
>>>>> There are several module with the same error. It's annoying to
>>>>> workaround them all. Could anybody help me?
>>>>>
>>>>> Thanks.
>>>>>
>>>>
>>>> What version of GNU Make do you use? 3.82 has a bug that let GNU Make
>>>> spit out this error even if the variable definition is OK (and is
>>>> parsed without problems by 3.81).
>>>
>>> I have run into this issue also on Win7. Cygwin has a current version of
>>> 3.82.90 (thus hitting 3.82 'bug').
>>> What is the best way to deal with this? Is this something that is
>>> considered a bug by gmake, or is this a regression that will continue?
>>> (it involves 'make -r' not working correctly and I guess does look like
>>> a regression - not a new feature)
>>> If we can move to a new syntax, without breaking any other platforms,
>>> but also using current Cygwin packages - would that would be the best
>>> solution?
>>>
>>> For now I will switch the instructions for the buildbot, call out the
>>> use of make 3.81-2 (which is also available in current Cygwin).
>>> At this point, this seems to be a solution for the build.
>>
>>
>> I reported the problem to cygwin several months ago:
>>
>> http://cygwin.com/ml/cygwin/2011-02/msg00398.html
>>
>> See also
>>
>> http://wiki.services.openoffice.org/wiki/Build_Environment_Effort/Status_And_Next_Steps
>>
>> At the end of the page you can see my instructions to build a custom version
>> of make. This gave me the best make on cygwin so far.
>>
>> This page mentions a performance bug in make 3.82 that we also found on
>> cygwin. It's possible that this was a problem of the HEAD version at that
>> time.
>>
>> Regards,
>> Mathias
>
>
>


Mime
View raw message