Add even more support for multiarch building.

[Artoria2e5]

Now the abbs repo contains a lot of explicitly-defined +32 packages, and most of them can be avoided with the arch stuffs just like we can merge armhf stuffs into the main abbs specs.

Here is the TODOs for some extended support:

• An associative array or some other data structures to define the compatibility between architectures. The main need is to see what else an arch can provide here, for the second point:
• A boolean to instruct ab to use the first arch in the can-provide list to build a package, so abbs can tell ab to do so.
• A string to override the arch selected, but it needs to be compatible with the base CROSS/ARCH arch, unless:
• A boolean to force building even if OVERRIDE doesn't match CROSS/ARCH, although it doesn't really matter...
• (Obsolete?) A scheme to add suffixes to PKGNAMES that is built with the specified multiarch, while keeping some PKGNAMES unchanged. See below for more info.

There is actually some problems introduced by d244003, which converts 32subsys to some arch form. It sets the $CROSS to i386, which will eventually be used by package managers as the target arch they are packing for. This may cause dependency problems when depending on amd64 stuffs, while the multiarch possibility also tells us that the suffix can be somehow deprecated.

BLOCKS:

• [x] What the fuck is a subsys?
  • now it's optenv.
• [ ] amend wording (#83)

[Artoria2e5]

Updates and TODOs.

We are not using any multiarch tricks, so to fix the stuffs we need an extra proc before any pm operations which puts the arches back to it's mother arch.

We are certainly adding some so-called subsystem support. It would be something more than the current multilib fakers, and it will be based on specially-formatted archnames.

The necessary fields are still TODOs.

[Artoria2e5]

Doc: Multiarch-extended

Use the arch abstraction to do more things.

Naming:

• basearch+subsys

Impl Sets:

• A: Utilize the CROSS stuff and feed it with even more things.

Proc Changes

\ Impl Set A1 **

New Proc: 79-flatarch.

# 79-flatarch
# Module: extarch
if [ "$CROSS" ]; then
  CROSS="${CROSS%%+*}"
fi

\ End Set A1 **

Arch Changes

\ Impl Set A1 ** @Icenowy I'm suggesting including autobuild/$CROSS, or Bai's abbs core packs with lots of amd64/build flying would compile differently when crossing to amd64.

# lib/arch.sh
ARCH_FINDFILELIST=("autobuild/cross-$ARCH-$CROSS" "autobuild/cross-$CROSS" "autobuild/$CROSS" "autobuild/$ARCH" "autobuild")
if [ "${BASEARCH[$CROSS]}" ]; then
  unset ARCH_FINDFILELIST[3] ARCH_FINDFILELIST[4]
  ARCH_FINDFILELIST+=("autobuild/cross-$ARCH-${BASEARCH[$CROSS]}" "autobuild/cross-${BASEARCH[$CROSS]}  "autobuild/${BASEARCH[$CROSS]}" "autobuild/$ARCH" "autobuild")
fi

# proc/11-flags.sh
. $ABLE/arch .............
: ${ARCH_EXEFORMAT=ELF}
# .............
if [ "$ARCH_PKGNAME_SUFFIX" ]; then
  PKGNAME+="$ARCH_PKGNAME_SUFFIX"
elif [[ "$CROSS" == *+* ]]
  PKGNAME+="+${CROSS##*+}"
fi

# arch/amd64+32.sh
# First move everything from i386.sh
# - [ "$CROSS" ] ... Delete the assert

# arch/amd64+w64.sh
# ??
ARCH_EXEFORMAT=PE

# arch/amd64+ubuntu.sh
. "$ABLE/arch/amd64.sh"
# Change Prefix, blah blah

\ End Set A1 **

[MingcongBai]

@Arthur2e5 I still think using "+" will be a better symbol for distinguishing between normal, and "extended-architecture" packages. Refer to Debian.

[Artoria2e5]

@MingcongBai Updated.

[MingcongBai]

@Arthur2e5 Thanks a lot.

[Artoria2e5]

Ah, we haven't made target stuff yet.

And we do need some renaming.

• ARCH should be called CURRARCH or whatever
• CROSS should be called PKGARCH
• blah

[Artoria2e5]

I need ideas! Now we need BUILD, HOST, and TARGET. A new naming scheme and fallback sequence in libarch is needed. A PKGNAME definition scheme is needed too.

[MingcongBai]

Like ${i}/+32 sort of schemes?

[Artoria2e5]

Exactly. We need to figure out how to post-fix the whole thing.

[MingcongBai]

May sound stupid, but I did thought of grep...

[Artoria2e5]

Say, PKGNAME+HOST+TARGET, and HOST can be omitted when it is the platform itself, and when TARGET is HOST, +TARGET can be omitted.

Therefore, we have

• booutils+32+armel: Spooky utils for handling candies being eaten armel, compiled for 32subsys.
• booutils++32: Spooky utils for handing candies being eaten in 32subsys, compiled for the current arch.
• booutils+32: Spooky utils for handling candies being eaten in 32subsys compiled for 32subsys.

[MingcongBai]

I would suggest rework you mind...

[Artoria2e5]

Well, actually in a naming scheme when we apply ab's archname strategy it will be booutils+i386…

[MingcongBai]

Looks better after the edit. But what about some long used metas namely linux+kernel? I hope they won't be...

[Artoria2e5]

parsing names can be stopped if the things figures out it it not an arch.

[Artoria2e5]

Need some rewording to match #83.

[Artoria2e5]

I don't think there are much to change here.. Basically:

• i386 → amd64+32 (also ABTARGET renames)

And we really don't need BASEARCH.

[Artoria2e5]

I guess we need to hack some offical_builds thing.

[Artoria2e5]

Bai Bai.. What should we do.. We need to move PREFIX when doing optenv builds(

[MingcongBai]

I mean... just manual set it...

[Artoria2e5]

I think I should always make HOST the final suffix anyway.

[MingcongBai]

I think I should always make HOST the final suffix anyway.

Which is appended to $AUTOTOOLS_DEF, this can be problematic if one would specify export AUTOTOOLS_DEF="" in, say, autobuild/prepare.

[Artoria2e5]

I am talking about +$ABHOST.

[MingcongBai]

Ah.

[MingcongBai]

I hate the emoji function... So distracting.

[Artoria2e5]

I guess I should try implementing this in acbs. The new retro overlay thing will benefit too.

[Artoria2e5]

The prefix switching does feel like something autobuild should be responsible for though...