View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005899||Taler||wallet (WebExtensions)||public||2019-09-18 15:21||2019-10-02 23:39|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0005899: portable configure|
|Description||The configure script is rather unportable. This does not only consider my situation with a BSD rooted|
implementation of find, xarg, getopt, but also Linux systems with no GNU userland tools (those exist
Is there a specific reason why normal failing when base tools used in the Makefile are not enough?
I could rewrite the Makefile in a way that it considers all possible / for us relevant implementations of those
tools (or use more portable invocations).
All know make implementations in my experience support passing a prefix to it.
We could just get away with an empty ./configure (for those who need it, ie mostly automation being stupid), or none at all.
|Tags||No tags attached.|
If portability is desired, we should rewrite ./configure in python3. Or rather, as a *very* simply shell (= /bin/sh) script that checks if python3 is installed and then executes some configure.py.
I don't really see any good reason to avoid the dependency on python3.
The reason I wrote the configure script: To be compatible with the GNU coding standards. There should be a configure script, and it should support --prefix.
We might even go the "Google approach" of having all build-related tooling in some git submodule. The ./configure would then make sure the submodule is initialized and run the python script from there.
Hm, okay. I don't fully understand the reasoning since it is a should and not a must, but having it in a python3 file sounds better.
Okay if I take on this and test it in Debian and NetBSD for compatibility with userlands? I could then start and export this once
it works into "building.git" or something like that.
||probably configure (shell script, tests for possible python3 executable name) and then calls the python3 script is the better approach.|
I agree that having it in Python3 sounds way better, even just because using argparse from the standard library is nicer than the current abomination in the ./configure.
Yes, please just start converting it into Python3 first. Later if we discover there's too much duplication on other repos, we can do some build.git.
> probably configure (shell script, tests for possible python3 executable name) and then calls the python3 script is the better approach.
Yes, that's exactly what I was suggesting :-)
Okay, thanks for the explanation.
private is probably not necessary for this ticket, okay to make it public (if mantis supports this change)?
||Sure, can be public!|
I'm about to push what I have.
This first version took so long because argparse is far from perfect and I needed to run into a couple of walls.
I learned that argparse is implemented in a way that it decides what your error handling should be, and opting out is not nice. In the end I decided to drop the 3rd branch I had and simply make argparse the default if no PREFIX environment variable is exported.
I expect that the prefix directory does exist. otherwise it becomes literally "None", which still has to be worked around.
||closing this, rest is ongoing work (migration, maintenance etc)|
|2019-09-18 15:21||ng0||New Issue|
|2019-09-18 15:21||ng0||Status||new => assigned|
|2019-09-18 15:21||ng0||Assigned To||=> Florian Dold|
|2019-09-18 15:27||Florian Dold||Note Added: 0014914|
|2019-09-18 15:35||ng0||Note Added: 0014915|
|2019-09-18 15:36||ng0||Note Added: 0014916|
|2019-09-18 15:37||Florian Dold||Note Added: 0014917|
|2019-09-18 15:37||Florian Dold||Note Added: 0014918|
|2019-09-18 15:39||ng0||Note Added: 0014919|
|2019-09-18 15:40||ng0||Assigned To||Florian Dold => ng0|
|2019-09-18 15:41||Florian Dold||Note Added: 0014920|
|2019-09-18 15:43||ng0||View Status||private => public|
|2019-09-20 18:58||ng0||Note Added: 0014927|
|2019-10-02 23:39||ng0||Note Added: 0014973|
|2019-10-02 23:39||ng0||Status||assigned => resolved|
|2019-10-02 23:39||ng0||Resolution||open => fixed|