| View previous topic :: View next topic |
| Author |
Message |
halcon
l33t
Joined: 15 Dec 2019
Posts: 649
|
 Posted: Thu Feb 11, 2021 12:35 am Post subject: |
 |
|
| asturm wrote: | | Handmade build scripts are consistently the worst case scenario for packaging. Better keep autotools then. |
Really? I did not know. Well, if so, then, I don't know when I deal with this, because I, in principle, agree with Tony0945's concept of autotools and am not sure when I bring myself to learn it...
_________________
A wife asks her husband, a programmer:
- Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6?
He comes back with 6 cartons of milk.
- Why did you buy 6 cartons of milk?
- They had eggs. |
|
| Back to top |
|
 |
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22654
|
| Posted: Thu Feb 11, 2021 2:15 am Post subject: |
|
|
| The problem with handmade scripts is that there is no guarantee that they will follow any particular standards. Will they understand how to install to a temporary directory structure (DESTDIR)? Will they call it by that name, or some other? Will they pick up the user's compiler flags from the usual place? If not, can they be made to use those flags without needing to patch the script? The advantage of the various build kits, such as autotools, is that the upstream developer does not need to handle any of those details. The generated code common to every project based on that kit will do the expected thing, unless upstream goes out of its way to override the usual behavior. This commonality is appealing to packagers, because they can learn autotools once, and then apply those lessons to every autotools-based package they work on. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1699
Location: South America
|
| Posted: Thu Feb 11, 2021 1:53 pm Post subject: |
|
|
| Hu wrote: | | The problem with handmade scripts is that there is no guarantee that they will follow any particular standards. |
Musl's build system, which has been copied by other packages such as s6 and s6-rc, is an interesting case. It has a "handmade" configuration script and makefiles, but the script's user interface has been made compatible with that of an Autoconf-generated one (i.e. taking GNU-style build systems as the 'standard').
As long as the configuration script is named configure and behaves correctly when invoked by econf, and the resulting makefile works correctly when the make program is invoked through emake during the compile and install phases, packaging for Gentoo should not be difficult. |
|
| Back to top |
|
|
halcon
l33t
Joined: 15 Dec 2019
Posts: 649
|
| Posted: Thu Feb 11, 2021 8:46 pm Post subject: |
|
|
Thanks for the tip, GDH-Gentoo.
I looked briefly at the musl's configure script and at the musl ebuild. If this 800-line script is compatible with Gentoo build system, then why the ebuild author doesn't call econf, but does instead
| Code: | ./configure \
--target=${CTARGET} \
--prefix=${sysroot}/usr \
--syslibdir=${sysroot}/lib \
--disable-gcc-wrapper || die |
?
Also, I compared pm-utils files before and after building. Some .in files do not differ with their no-.in instances at all, for example, functions.in is equal to functions. So, functions.in can be renamed to just functions without any harm. But for renaming other files I would need to get values of @PM-UTILS-LIBDIR@ and @PM-UTILS-SYSCONFDIR@ as they were while configuring. So, I decided to look how it is done in hibernate-script, looked at the code... and it did not help much:
https://gitlab.com/nigelcunningham/Hibernate-Script/-/blob/master/install.sh#L12
| Code: | | [ -z "$CONFIG_DIR" ] && CONFIG_DIR=${BASE_DIR}${CONFIG_PREFIX}/etc/hibernate |
https://gitlab.com/nigelcunningham/Hibernate-Script/-/blob/master/hibernate.sh#L57
| Code: | SWSUSP_D="/etc/hibernate"
SCRIPTLET_PATH="$SWSUSP_D/scriptlets.d /usr/local/share/hibernate/scriptlets.d /usr/share/hibernate/scriptlets.d"
DEFAULT_CONFIG_FILE="$SWSUSP_D/hibernate.conf" |
https://gitlab.com/nigelcunningham/Hibernate-Script/-/blob/master/hibernate.sh#L499
| Code: | # CheckImplicitAlternateConfig <$0> : checks $0 to see if we should be
# implicitly using a different configuration file.
CheckImplicitAlternateConfig() {
# Don't find one if we've already been specified one.
[ -n "$CONFIG_FILE" ] && return 0
local self
self="${0##*/}"
case $self in
hibernate-*)
CONFIG_FILE="$SWSUSP_D/${self#hibernate-}.conf"
vecho 3 "$EXE: Using implicit configuration file $CONFIG_FILE"
;;
*)
CONFIG_FILE="${DEFAULT_CONFIG_FILE}"
;;
esac
return 0
} |
https://gitlab.com/nigelcunningham/Hibernate-Script/-/blob/master/hibernate.sh#L528
| Code: | case $opt in
-F|--config-file)
CONFIG_FILE="${1#\'}"
CONFIG_FILE="${CONFIG_FILE%\'}" |
As far as I understand, if $CONFIG_DIR is changed to a non-default value during configuring, and then the location of .conf file is not passed explicitly as option -F, .conf file won't be found.
So, the question remains open: is there a way for a bash script to get his SYSCONFDIR and LIBDIR? The easiest solution that comes to my mind is to write those values while configuring in some text file and then to read it 
_________________
A wife asks her husband, a programmer:
- Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6?
He comes back with 6 cartons of milk.
- Why did you buy 6 cartons of milk?
- They had eggs.
Last edited by halcon on Thu Feb 11, 2021 11:59 pm; edited 1 time in total |
|
| Back to top |
|
|
halcon
l33t
Joined: 15 Dec 2019
Posts: 649
|
| Posted: Thu Feb 11, 2021 9:06 pm Post subject: |
|
|
| Hu wrote: | | This commonality is appealing to packagers, because they can learn autotools once, and then apply those lessons to every autotools-based package they work on. |
Yes, considering the number of projects that use autotools, learning it is definitely worth it... Though...   If there is such a campaign against C/C++ (Rust, Swift, etc), nothing is eternal under the sun and the moon...
_________________
A wife asks her husband, a programmer:
- Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6?
He comes back with 6 cartons of milk.
- Why did you buy 6 cartons of milk?
- They had eggs. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1699
Location: South America
|
| Posted: Fri Feb 12, 2021 1:43 pm Post subject: |
|
|
| halcon wrote: | | I looked briefly at the musl's configure script and at the musl ebuild. If this 800-line script is compatible with Gentoo build system, then why the ebuild author doesn't call econf, but does instead [...] |
I don't know. It looks like econf could have been used without any problems.
| halcon wrote: | | Also, I compared pm-utils files before and after building. [...] But for renaming other files I would need to get values of @PM-UTILS-LIBDIR@ and @PM-UTILS-SYSCONFDIR@ as they were while configuring. |
pm-utils handles that with a makefile fragment that calls sed. This is pretty common.
pm/Makefile.am
| Code: | pm_libdir = $(libdir)/pm-utils
pm_sysconfdir = $(sysconfdir)/pm
#...
do_subst = sed -e 's,[@]PM-UTILS-LIBDIR[@],$(pm_libdir),g' \
-e 's,[@]PM-UTILS-SYSCONFDIR[@],$(pm_sysconfdir),g'
SUFFIXES = .in
.in:
$(do_subst) $< >$@
chmod +x $@ |
| halcon wrote: | So, I decided to look how it is done in hibernate-script, looked at the code... and it did not help much:
[...]
As far as I understand, if $CONFIG_DIR is changed to a non-default value during configuring, and then the location of .conf file is not passed explicitly as option -F, .conf file won't be found. |
Yeah, it seems to be that way. |
|
| Back to top |
|
|
Princess Nell
l33t
Joined: 15 Apr 2005
Posts: 926
|
| Posted: Sun Feb 14, 2021 12:59 pm Post subject: |
|
|
| Replacing functions.in with functions because the listed substitutions aren't made is misleading because the perceived gain of efficiency now can cause more work in the long term. We can infer that at some point in the past those variables were present in the file, and potential future development could put them back or even add others. |
|
| Back to top |
|
|
halcon
l33t
Joined: 15 Dec 2019
Posts: 649
|
| Posted: Sun Feb 14, 2021 2:54 pm Post subject: |
|
|
| Princess Nell wrote: | | Replacing functions.in with functions because the listed substitutions aren't made is misleading because the perceived gain of efficiency now can cause more work in the long term. We can infer that at some point in the past those variables were present in the file, and potential future development could put them back or even add others. |
Okay. I can see its advantages now (as compared with /etc handling in hibernate-script).
_________________
A wife asks her husband, a programmer:
- Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6?
He comes back with 6 cartons of milk.
- Why did you buy 6 cartons of milk?
- They had eggs. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
