mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Separate build rules (was Re: [Mingw-cross-env-list] Mingw64)


From: Tony Theodore
Subject: Re: Separate build rules (was Re: [Mingw-cross-env-list] Mingw64)
Date: Sun, 19 Dec 2010 03:16:07 +1100

On 18 December 2010 18:03, Tony Theodore <address@hidden> wrote:
> Hi Volker,
>
> Thanks for the long reply, I finally found some time to think about this 
> again.
>
> On 17 September 2010 21:10, Volker Grabsch <address@hidden> wrote:
> [...]
>> I thought that for the first step of simply using mingw-w64 to
>> build 32-bit-only, this wouldn't be necessary. It is important
>> to reach complete 32-bit support with mingw-w64 first, without
>> being distracted by 64-bit details that aren't relevant yet.
>
> I think complete 32-bit support is still a fair way off for mingw-w64.
> I'd rather see continued 32-bit support using mingw.org and a subset
> of 64-bit packages.
>
>> Having said that, here's my current plan.
>>
>> (I'll introduce the new stuff in Mingw-cross-env and convert all
>>  *.mk files if you really need that for your actual work now.)
>
> Thanks, I'm in no need of this in the near future and I think it will
> be years before it becomes a major issue.

Having said that, I thought I'd go ahead with a proof-of-concept,
changesets attached.

>> First, we replace $(TARGET) with $(TARGETS):
>> Then, each src/*.mk file contains multiple $(PKG)_BUILD rules:
>> The "install"-markers get a CPU suffix:

These are fairly straightforward.

>> There might be other places to be adjusted, too.
>
> Maybe ./log becomes ./log-$(TARGET) ?

This was necessary as the timestamp doesn't change.

>> Packages without 64-bit support have an empty BUILD_x86_64 rule.
>
> I imagine the empty rules will always succeed so the install marker
> will be written.

For the time being, I have empty (missing) build rules outputting to
the console. We may need to do something else here for the case of
missing dependencies.

>> Packages that have identical rules for 32/64 bit can be written as:
>>
>>    define $(PKG)_BUILD_i686
>>        ...
>>    endef
>>
>>    define $(PKG)_BUILD_x86_64
>>        $(mypackage_BUILD_i686)
>>    endef
>>
>> Note that you _can't_ use "$($(PKG)_BUILD_i686)" here yet. [1]

This is probably the most interesting part of the exercise. Initially,
$(TARGET) was out-of-scope also, and I managed to find
"Target-specific Variable Values":

http://www.gnu.org/software/make/manual/make.html#Target_002dspecific

Now we can use the $($(PKG)_BUILD_i686) construct, and also use the
same to clean up SUBDIR, BUILD_DIR etc.

> Agreed, we can always use some variables for common parts:
>
>    $(PKG)_CONFIGURE_OPTIONS := ...

I've made no effort to consolidate or simplify the package rules yet,
other than confirming the follow works (see openssl):

    define $(PKG)_BUILD_x86_64
        $(subst mingw ,mingw64 ,$($(PKG)_BUILD_i686))
    endef

Please let me know what you think.

Cheers,

Tony

Attachment: multiple-targets.diff
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]