Skip to content

Proposed way to add breakpoints to easybuild #5036

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 3 commits into
base: develop
Choose a base branch
from
Open

Proposed way to add breakpoints to easybuild #5036

wants to merge 3 commits into from

Conversation

@Crivella
Copy link
Contributor

@Crivella Crivella commented Oct 30, 2025 •
edited
Loading

Feature proposed during the 2025-10-22 EB confcall

Adds a new --breakpoints option that takes a comma-separated list of breakpoint names.
The names should be the same as those for available hooks (with or without the trailing _hook suffix).

EB will drop you into an interactive shell with the same environment (before the corresponding hook would be ran)

TODO

  • Tests
  • BP name validation

Maybe

  • Customizable prompt / coloring

How does this look

(easybuild-dev) crivella@crivella-desktop:~$ eb --installpath=$(mktemp -d) -d --rebuild --breakpoints start,post_configure zlib-1.3.1-GCCcore-14.3.0.eb 
== Temporary log file in case of crash /home/crivella/.local/easybuild/logs/easybuild-fuaw57ut.log
easybuild-breakpoint> printenv | grep '^EB'
EB_SCRIPT_PATH=/home/crivella/.virtualenvs/easybuild-dev/bin/eb
easybuild-breakpoint> exit 
exit

WARNING: Index for /home/crivella/Documents/GIT/easybuild-easyconfigs/easybuild/easyconfigs is no longer valid (too old), so ignoring it...


WARNING: Index for /home/crivella/Documents/GIT/easybuild-easyconfigs/easybuild/easyconfigs is no longer valid (too old), so ignoring it...

== processing EasyBuild easyconfig /home/crivella/Documents/GIT/easybuild-easyconfigs/easybuild/easyconfigs/z/zlib/zlib-1.3.1-GCCcore-14.3.0.eb
== building and installing zlib/1.3.1-GCCcore-14.3.0...
  >> installation prefix: /tmp/tmp.bcDeYVNMdv/software/zlib/1.3.1-GCCcore-14.3.0
== fetching files and verifying checksums...
  >> sources:
  >> /home/crivella/.local/easybuild/sources/z/zlib/zlib-1.3.1.tar.gz [SHA256: 9a93b2b7dfdac77ceba5a558a580e74667dd6fede4585b91eefb60f03b72df23]
== ... (took < 1 sec)
== creating build dir, resetting environment...
  >> build dir: /home/crivella/.local/easybuild/build/zlib/1.3.1/GCCcore-14.3.0
== ... (took < 1 sec)
== unpacking...
  >> running shell command:
	tar xzf /home/crivella/.local/easybuild/sources/z/zlib/zlib-1.3.1.tar.gz
	[started at: 2025-10-30 16:36:18]
	[working dir: /home/crivella/.local/easybuild/build/zlib/1.3.1/GCCcore-14.3.0]
	[output and state saved to /tmp/eb-jjxd16gl/run-shell-cmd-output/tar-y7er46cw]
  >> command completed: exit 0, ran in < 1s
== ... (took < 1 sec)
== patching...
== ... (took < 1 sec)
== preparing...
  >> loading toolchain module: GCCcore/14.3.0
  >> loading modules for build dependencies:
  >>  * binutils/2.44
  >> (no (runtime) dependencies specified)
  >> defining build environment for GCCcore/14.3.0 toolchain
== ... (took < 1 sec)
== configuring...
  >> running shell command:
	./configure --prefix=/tmp/tmp.bcDeYVNMdv/software/zlib/1.3.1-GCCcore-14.3.0
	[started at: 2025-10-30 16:36:18]
	[working dir: /home/crivella/.local/easybuild/build/zlib/1.3.1/GCCcore-14.3.0/zlib-1.3.1]
	[output and state saved to /tmp/eb-jjxd16gl/run-shell-cmd-output/configure-uwljw6s5]
  >> command completed: exit 0, ran in 00h00m01s
easybuild-breakpoint> printenv | grep '^EB'
EBVARLDFLAGS=-L/home/crivella/.local/easybuild/software/binutils/2.44/lib64 -L/home/crivella/.local/easybuild/software/binutils/2.44/lib -L/home/crivella/.local/easybuild/software/GCCcore/14.3.0/lib64 -L/home/crivella/.local/easybuild/software/GCCcore/14.3.0/lib
EBVARCXX=g++
EBVERSIONBINUTILS=2.44
EBROOTBINUTILS=/home/crivella/.local/easybuild/software/binutils/2.44
EBVARF90=gfortran
EBVARFC=gfortran
EBDEVELGCCCORE=/home/crivella/.local/easybuild/software/GCCcore/14.3.0/easybuild/GCCcore-14.3.0-easybuild-devel
EBVAROPTFLAGS=-O2 -ftree-vectorize -march=native
EBVARCC=gcc
EBVARFCFLAGS=-O2 -ftree-vectorize -march=native -fno-math-errno -fPIC
EBVARPRECFLAGS=-fno-math-errno
EBVARLIBS=-lm -lpthread
EBVARFFLAGS=-O2 -ftree-vectorize -march=native -fno-math-errno -fPIC
EBVARCXXFLAGS=-O2 -ftree-vectorize -march=native -fno-math-errno -fPIC
EBROOTGCCCORE=/home/crivella/.local/easybuild/software/GCCcore/14.3.0
EBVARCPPFLAGS=-I/home/crivella/.local/easybuild/software/binutils/2.44/include
EBVARFLIBS=-lgfortran
EBVARF77=gfortran
EBDEVELBINUTILS=/home/crivella/.local/easybuild/software/binutils/2.44/easybuild/binutils-2.44-easybuild-devel
EB_SCRIPT_PATH=/home/crivella/.virtualenvs/easybuild-dev/bin/eb
EBVERSIONGCCCORE=14.3.0
EBVARCFLAGS=-O2 -ftree-vectorize -march=native -fno-math-errno -fPIC
EBVARF90FLAGS=-O2 -ftree-vectorize -march=native -fno-math-errno -fPIC
easybuild-breakpoint> echo $LDFLAGS 
-L/home/crivella/.local/easybuild/software/binutils/2.44/lib64 -L/home/crivella/.local/easybuild/software/binutils/2.44/lib -L/home/crivella/.local/easybuild/software/GCCcore/14.3.0/lib64 -L/home/crivella/.local/easybuild/software/GCCcore/14.3.0/lib
easybuild-breakpoint> exit
exit
== ... (took 25 secs)
== building...
  >> running shell command:
	make  -j 8
	[started at: 2025-10-30 16:36:44]
	[working dir: /home/crivella/.local/easybuild/build/zlib/1.3.1/GCCcore-14.3.0/zlib-1.3.1]
	[output and state saved to /tmp/eb-jjxd16gl/run-shell-cmd-output/make-jj82nypl]
  >> command completed: exit 0, ran in 00h00m01s
== ... (took 1 secs)
== testing...
== ... (took < 1 sec)
== installing...
  >> running shell command:
	make install
	[started at: 2025-10-30 16:36:45]
	[working dir: /home/crivella/.local/easybuild/build/zlib/1.3.1/GCCcore-14.3.0/zlib-1.3.1]
	[output and state saved to /tmp/eb-jjxd16gl/run-shell-cmd-output/make-7rahlsi6]
  >> command completed: exit 0, ran in < 1s
== ... (took < 1 sec)
== taking care of extensions...
== ... (took < 1 sec)
== restore after iterating...
== ... (took < 1 sec)
== postprocessing...
== ... (took < 1 sec)
== sanity checking...
  >> file 'include/zconf.h' found: OK
  >> file 'include/zlib.h' found: OK
  >> file 'lib/libz.a' found: OK
  >> file 'lib/libz.so' found: OK
  >> loading modules: zlib/1.3.1-GCCcore-14.3.0...
== ... (took < 1 sec)
== cleaning up...
== ... (took < 1 sec)
== creating module...
  >> generating module file @ /tmp/tmp.bcDeYVNMdv/modules/all/zlib/1.3.1-GCCcore-14.3.0.lua
== ... (took < 1 sec)
== permissions...
== ... (took < 1 sec)
== packaging...
== ... (took < 1 sec)
== COMPLETED: Installation ended successfully (took 28 secs)
== Results of the build can be found in the log file(s) /tmp/tmp.bcDeYVNMdv/software/zlib/1.3.1-GCCcore-14.3.0/easybuild/easybuild-zlib-1.3.1-20251030.163646.log
== Build succeeded for 1 out of 1
== Summary:
   * [SUCCESS] zlib/1.3.1-GCCcore-14.3.0
== Temporary log file(s) /home/crivella/.local/easybuild/logs/easybuild-fuaw57ut.log* have been removed.
== Temporary directory /tmp/eb-jjxd16gl has been removed.

@hattom
Copy link
Contributor

hattom commented Nov 6, 2025

Is there any benefit to having the option to jump into a python prompt? (Would that already be possible somehow with pdb?)

@Crivella
Copy link
Contributor Author

Crivella commented Nov 7, 2025

You mean something like adding a --breakpoint-type to say if you want to drop in in a bash shell or a python one?
Might be interesting, but i feel like dropping into a python shell only when hooks are triggered might not give the granularity that one might desire.
Probably using a debugger for that as you suggested might be better.

My main usecase for this is to test stuff in a build environment at the start/end of a step when you don't have a cmd.sh that you can use to drop into a shell

@hattom
Copy link
Contributor

hattom commented Nov 7, 2025

Essentially yes. My thinking being that if you drop into a bash shell, you still can't understand why EB is doing what it's doing, and some way to interrogate the internal structures/variables might be useful.
I'm aware you can probably do this with pdb, but I wouldn't know how to do it without a lot of trial/error.

Your usecase makes perfect sense, I was just wondering if getting at the internal state might be useful as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

feature

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@Crivella @hattom