Well, duh... (saving configure args)

Core Workflow
1

This is one of those things I don’t know where to post. Feel free to flame me for selecting this group, or move it somewhere you think is more appropriate. Sorry, it also turned out to be longer than I thought.

I don’t really do much development anymore, but I still like to track changes to recent branches. Every now and then, my sorta old-and-weird personal environment reveals a minor problem. Every day or two I get bored and run something like

git fetch --all
git pull
nice make -j test

Sometimes I need to re-run configure or want to add another argument to the configure command line to enable something I normally live without. I will

grep configure config.status

then copy/paste the relevant configure command line to the shell prompt and (maybe) add new arg(s). That’s fine as far as it goes, as I don’t often need to do that. I’m sure there’s a way to add the args when rerunning config.status, but I’ve never bothered to figure it out.

The problem arises when I sometimes need to run git clean -fdx because the Makefile dependencies aren’t perfect and the loader got its knickers in a twist. So it’s

git clean -fdx
./configure
nice make -j test

except now I’ve lost whatever args were lurking in config.status. Dang. Then I came up with this:

mv config.status ..
git clean -fdx
mv ../config.status .
./config.status --recheck
nice make -j test

Much better, but man, I still have to remember the mv commands. And anyway, I’m a (retired) software engineer, so by nature, I’m lazy. That’s two whole extra commands! Plus if I’m super lazy one day and forget them, I’m back to square one.

Today it finally (after what, 30 years?) dawned on me that I could stash my configure args in my own file! My Mac’s directory structure looks like this:

/Users/skip
    /src
        /python
            /cpython
            /3.13
            /3.12

(similar on my old Dell laptop and Raspberry Pi)

I created a file named config-args.cpython in my .../src/python directory, where git clean can’t find it:

--enable-framework=./framework
--with-framework-name=fred
--with-openssl=/opt/homebrew/Cellar/openssl@3/3.3.1
--with-readline=readline
LIBREADLINE_CFLAGS=-I/opt/homebrew/Cellar/readline/8.2.10/include
LIBREADLINE_LIBS='-L/opt/homebrew/Cellar/readline/8.2.10/lib -lreadline'
LIBB2_CFLAGS='-I/opt/homebrew/include'
PKG_CONFIG=/opt/homebrew/Cellar/pkg-config/0.29.2_3/bin/pkg-config

and can rerun configure using xargs:

xargs ./configure << ../config-args.cpython

The process is similar for the 3.13 and 3.12 branches. Oh, and I could easily have multiple “mixin” arg files, say for building with different compilers or different OpenSSL versions. That suggests a slightly different xargs command:

cat ../config.args.cpython ../config.args.g++ ../config.args.framework | xargs ./configure

This will be useful for maybe three people in the next decade, and will probably shake loose thirty-seven better ways of skinning this cat(*) which never occurred to me, but this seems good enough for now.

(*) Please don’t tell anybody on Threads that I occasionally skin cats. I will never hear the end of it.

1 Like
2

Alice: “There’s more than one way to skin a cat, if you’ll pardon the expression.”
Cheshire Cat: “Most unpleasant metaphor. Please avoid it in future.”

I’ve never needed this many args, as the most I generally need to do is turn on optimizations. But is it --with-optimizations or --enable-optimizations or do you leave off the s or is it something else? I usually get it wrong the first time, end up configuring without them, and then use the message at the end of configure to tell me what the flag really is, and then rerun it. So this strategy would benefit me. Since that’s the ONLY command I need, though, I don’t need the mixins.

I’m not sure that xargs is needed here though. Can you do the whole thing with backtick interpolation?

./configure `cat ../config-args.cpython`

./configure `cat ../config.args.{cpython,g++,framework}`

At very least, I would take advantage of brace/comma expansion (assuming you’re on bash, zsh, or another shell with that support) to avoid typing out the common part more than once - less error-prone that way.

But broadly speaking I think that your strategy is sound, and miles better than what I do :smiley:

1 Like
3

I also don’t generally need as many configure arguments or combinations, but for the small set of combinations that I do use, I just create a little sh script to collect the common ones, set an environment variable or two, and then call configure, always with a trailing $* so I can add a few rare occasional things on the command line. Simple works for me!

For ages, I’ve had a git alias I use all the time:

# ~/.gitconfig
[alias]
    distclean = "clean -dxffi"

so git distclean [1] is an oft-used helper.

  1. so name inspired from a common make target ↩︎

1 Like
4

I side step this problem of recovering how it was built by create a shell script to build anything like this.

In my case I then edit the script to update the build steps.

2 Likes
5

Barrys think alike! :smile:

3 Likes
6

Yeah, I thought about writing a shell script, but then I’d have to figure out where to put it (I have a few “bin” directories), making sure it was sandbox agnostic, and would have trouble remembering the name from one use to the next (recall, this isn’t a frequent operation). It would be in my zsh/bash history, but still…

7

Yeah, backticks. Another one of those skinned cats. I wish the myriad shells were a bit more like Python in this regard. “There should be one-- and preferably only one --obvious way to do it.” :wink:

8

I use the name build.sh and put in the project specific folder not in ~/bin.