[Top][All Lists]
[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
multiple-targets.diff
Description: Binary data