[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpm-devel
Subject:    Re: compiliation without langinfo.h
From:       Peter Kalbus <peter.kalbus () gmx ! de>
Date:       2008-01-24 21:42:23
Message-ID: 2A07ECE0-15D1-4883-9F00-67F7E850F998 () gmx ! de
[Download RAW message or body]

as rpm5 needs beecrypt and at least on qnx i need m4 to get beecrypt  
compiled, the assumption seems to be valid. at least in the way, that  
m4 is possible to be installed on the qnx system. but as the beecrypt  
maybe installed from a binary distribution, the availability cannot bu  
guarenteed from this assumption.

let me know, if m4 will become a requirement for rpm5, so i can add  
this to the pkgsrc makefile.

-piet


Am 24.01.2008 um 22:26 schrieb Ralf S. Engelschall:

> On Thu, Jan 24, 2008, Jeff Johnson wrote:
>
>>
>> On Jan 24, 2008, at 3:27 PM, Ralf S. Engelschall wrote:
>>
>>> On Thu, Jan 24, 2008, Jeff Johnson wrote:
>>>
>>>>
>>>> On Jan 24, 2008, at 2:20 PM, Peter Kalbus wrote:
>>>>
>>>>> great.
>>>>>
>>>>> i've switched to lates snapsot and i can remove two patches from  
>>>>> my
>>>>> local
>>>>> patches directory :)
>>>>>
>>>>> now there are only 8 patches left ;-)
>>>>>
>>>>
>>>> Send a URI to the patches, and I'll try to fold them into rpm-5.0.1
>>>>
>>>> At a minimum, I'll add a #ifdef RPM_QNX (or equiv) to carry the  
>>>> patches.
>>>
>>> Use #ifdef RPM_OS_QNX ...
>>
>> Will do. While I have yer attention ...
>>
>> How should per-os expansions be handled?
>>
>> I'll need to whack in some changes to macros.in to handle
>> DB_PRIVATE on QNX?
>>
>> Generating a platform specific macros file is easy alternative, but
>> there are perhaps other distros (SuSE comes to mind)
>> that wish DB_PRIVATE and a coarse grained shared/exclusive
>> fcntl lock as rpm-3.0.x used to use.
>
> We either could go the way of platform specific macros files or run
> a pre-processor like m4(1) or cpp(1) over the "macros" file during
> build-time and pass it also the RPM_OS_XXX and similar flags. For
> OpenPKG I also has this problem: I need the remove(!) or at least
> out-comment the %_host* macros. So, I personally would like to see the
> preprocessor solution. cpp(1) might choke on the macros content (have
> not checked), but m4(1) is certainly happy about the stuff. Remains
> just the question whether we can assume that m4(1) is available during
> build-time of RPM, but it should be acceptable to assume this...
>
>                                       Ralf S. Engelschall
>                                       rse@engelschall.com
>                                       www.engelschall.com
>
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org

______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org
[prev in list] [next in list] [prev in thread] [next in thread]