Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

buildsystem: rework build script #2151

Merged
merged 11 commits into from
Nov 22, 2017

Conversation

InuSasha
Copy link
Member

@InuSasha InuSasha commented Oct 27, 2017

Done:

  • combine PKG_AUTORECONF, PKG_USE_MESON, PKG_USE_CMAKE, PKG_USE_NINJA in to one PKG_TOOLCHAIN
  • replace some cascading if-elif-else-fi blocks with more readable case-blocks
  • add manual toolchain, with only run configure, make and makeinstall if defined in package.mk
  • reduce same more cascaded if-blocks (stamp and virtual)

Open:

  • none yet

Test: 28. 10

  • build: Generic, RPi1/2, Odroid, WeTek H/C/P1/P2 like master (incl. addons)
  • run: none

comments?

scripts/build Outdated
elif [ -f $PKG_BUILD/Makefile ]; then
PKG_TOOLCHAIN="make"
else
echo "Not possible to detect toolchain automactcly. Add PKG_TOOLCHAIN= in to package.mk"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo + wording:

echo "Not possible to detect toolchain automatically. Add PKG_TOOLCHAIN= to package.mk"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... c++ is much more easier then english :)

scripts/build Outdated
$PKG_TOOLCHAIN != "manual" ]; then
printf "$(print_color bold-red "ERROR: ")unknown toolchain $PKG_TOOLCHAIN"
exit 1
fi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could use...

  if ! listcontains "meson cmake cmake-make configure make autotools manual" "$PKG_TOOLCHAIN"; then
    printf "$(print_color CLR_ERROR "ERROR: ")unknown toolchain $PKG_TOOLCHAIN"
    exit 1
  fi

Also changed to use predefined CLR_ERROR for errors.

scripts/build Outdated
printf "$(print_color bold-red "ERROR: ")unknown toolchain $PKG_TOOLCHAIN"
exit 1
fi
printf "%${BUILD_INDENT}c $(print_color CLR_TOOLCHAIN "TOOLCHAIN ")$PKG_TOOLCHAIN${_auto_toolchain}\n" ' '>&$SILENT_OUT
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit - stylistically this is inconsistent with existing usage, eg.:

printf "%${BUILD_INDENT}c $(print_color CLR_UNPACK "UNPACK")   $1\n" ' '>&$SILENT_OUT

The spaces follow the call to print_color, so your line should be:

-      printf "%${BUILD_INDENT}c $(print_color CLR_TOOLCHAIN "TOOLCHAIN    ")$PKG_TOOLCHAIN${_auto_toolchain}\n" ' '>&$SILENT_OUT 
+      printf "%${BUILD_INDENT}c $(print_color CLR_TOOLCHAIN "TOOLCHAIN")    $PKG_TOOLCHAIN${_auto_toolchain}\n" ' '>&$SILENT_OUT

MilhouseVH
MilhouseVH previously approved these changes Oct 27, 2017
@MilhouseVH MilhouseVH dismissed their stale review October 27, 2017 13:37

Didn't want to approve just yet!

@MilhouseVH
Copy link
Contributor

Looks like a generally positive change... to avoid constant rebasing this needs to go in sooner than later. I'll run some local builds.

@InuSasha
Copy link
Member Author

@MilhouseVH will fix you comments, add finish my open todos, this evening (CEST).

"target") _pkg_depends="$PKG_DEPENDS_TARGET";;
"host") _pkg_depends="$PKG_DEPENDS_HOST";;
"init") _pkg_depends="$PKG_DEPENDS_INIT";;
"bootstrap") _pkg_depends="$PKG_DEPENDS_BOOTSTRAP";;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer a catch-all here:

  *) _pkg_depends=;;

or initialise _pkg_depends= (or unset _pkg_depends) before the case. It shouldn't be set to anything, of course, but who knows what variables will be set when sourcing other files - the package.mk is sourced shortly before this section and it can set anything it likes.

I'd even be inclined to wrap the for loop in a test, just for clarity:

if [ -n "$_pkg_depends" ]; then
  <for loop>
fi

bash will drop straight through the loop when _pkg_depends is blank or unset, but it avoids any confusion...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure about the the extra if. I do not like extra code.
The unset is added, will commit later.

@MilhouseVH
Copy link
Contributor

Adding ?w=1 makes some of these commits easier to review. :)

printf "%${BUILD_INDENT}c $(print_color CLR_BUILD "BUILD") $PACKAGE_NAME $(print_color CLR_TARGET "($TARGET)")\n" ' '>&$SILENT_OUT
export BUILD_INDENT=$((${BUILD_INDENT:-1}+$BUILD_INDENT_SIZE))

# virtual packages dont must be build, they only contains dependencies, so dont go further here
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This (old) comment is contradictory, maybe we can improve it?

# virtual packages don't build - they only contain dependencies, so don't go further here

?

@MilhouseVH
Copy link
Contributor

How do you feel about replacing md5sum with sha256sum when calculating the stamps? Is it even worth doing (what are the chances of a collision)? Could be left for a separate PR.

@InuSasha
Copy link
Member Author

sha256 takes more time. The advantage of sha256 over md5 is the security (but not relevant here).
I have never heard about problems with collisions.
I would leave it as is.

@MilhouseVH
Copy link
Contributor

Fair enough.

@InuSasha
Copy link
Member Author

clean builds of many archs run over night. I think, i had fixed every package, now.

@MilhouseVH
Copy link
Contributor

Just to add some background on the buildsystem: remove grep from PKG_ARCH check change:

The following test cases now work:

TARGET_ARCH PKG_ARCH RESULT
arm continue
arm arm continue
arm any continue
arm any !x86_64 continue
x86_64 any !x86_64 exit 0
arm aarch64 x86_64 exit 0
aarch64 aarch64 x86_64 continue
arm !x86_64 exit 0
arm !arm exit 0
arm !arm arm exit 0
arm !arm any exit 0

The old grep based method had three issues:

  1. it could not support PKG_ARCH="any -arm" (it used - to denote exclusion, which I've changed to ! as we don't currently have any packages using this notation)
  2. it ran the risk of incorrectly matching an arch if $TARGET_ARCH is ever a subset of a longer arch, eg. TARGET_ARCH=arm would incorrectly match against PKG_ARCH="aarch64 arm64" (fictitious example but you get the point)
  3. it uses sub-processes (which are evil 😄 )

This update fixes all three issues.

@InuSasha
Copy link
Member Author

rebase and fix after merge of #2100

@InuSasha
Copy link
Member Author

InuSasha commented Nov 2, 2017

rebase and fix addon docker after #1670

@lrusak
Copy link
Member

lrusak commented Nov 14, 2017

Generally I am ok with this. It doesn't really change anything but adds a bit more readability.

@InuSasha
Copy link
Member Author

good to hear :)
i will do a rebase, this evening (UTC+1).

@InuSasha
Copy link
Member Author

  • rebased on master.
  • include same changes need of merges on master

a generic with addons is done. build on the other project are running, actual.

@InuSasha
Copy link
Member Author

other builds are done. looks good.
@lrusak this can go in, now

@lrusak
Copy link
Member

lrusak commented Nov 21, 2017

@MilhouseVH can we hold all other PR's and test this please. If it builds just shove it in

I'd also like this to be squashed

@MilhouseVH
Copy link
Contributor

OK I'll build it clean overnight and merge if OK (and squashed).

InuSasha and others added 2 commits November 22, 2017 00:49
More efficient, slightly more functional.

Can be a space delimited list of architectures.

Architectures to be excluded can be specified with !ARCH.

Allows "any !arm" to be interpreted as "any arch, but not arm".

Blank/undefined is equivalent to "any".
@MilhouseVH MilhouseVH merged commit 3192ddf into LibreELEC:master Nov 22, 2017
@CvH CvH mentioned this pull request Nov 25, 2017
@InuSasha InuSasha deleted the feature/rewrite-build branch November 26, 2017 11:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants