[AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux

Autres projets et contributions
Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10499
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par FoolEcho » sam. 19 oct. 2013, 13:24

Oui, c'est clairement plus élégant à présent. :)
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » sam. 19 oct. 2013, 17:38

D'accord. On y est arrivé ! :mrgreen:

J'en ai profité pour rendre plus propre les paquets non-multilib (virer le français, et cetera) et calquant une bonne partie du travail sur les paquets multilib.
J'ajoute que j'ai mis à jour le dépôt, il est donc dorénavant basé sur ces nouveaux paquets : https://github.com/X0rg/Arch-PKGs/wiki/ ... repository

Voilà, je crois que c'est tout. Il ne me reste plus qu'à demander la suppression de lib32-gnustep-clang-svn et ça sera bon. :wink:
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » dim. 01 déc. 2013, 22:50

Plus de nouvelles du développeur principal, je crois que le projet meurt. Ça valait le coup dit donc de faire tout ce cirque pour ça... :bravo:
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10499
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par FoolEcho » lun. 02 déc. 2013, 09:33

Pour la beauté du geste. :mrgreen:
Ça ne me surprend pas du fait de la complexité de la compilation déjà, ce n'est guère maintenable. À voir.
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » dim. 04 mai 2014, 00:57

Bonsoir.

Je viens de réaliser qu'avec ldconfig, il y a sans doute moyen de faire quelque chose de plus "propre".
En effet, si par exemple je créé un fichier /etc/ld.so.conf.d/gnustep.conf qui contiendrait par exemple ceci :

Code : Tout sélectionner

/usr/share/GNUstep/lib
Alors dans ce cas là, ld trouvera automatiquement les bibliothèques, et je n'aurais plus besoin d'utiliser des exécutables alternatifs comme celui-ci :

Code : Tout sélectionner

#!/usr/bin/sh

export LD_LIBRARY_PATH=/usr/share/GNUstep/lib
/usr/share/$pkgname/mon_executable
Ni d'utiliser LDFLAGS, comme par exemple :

Code : Tout sélectionner

LDFLAGS="-L/usr/share/GNUstep/lib -L/usr/lib"
Mais je n'ai pas l'impression que ldconfig soit très utilisé de cette façon dans ArchLinux. Il faut dire que je viens de regarder, et aucun paquet a des bibliothèques (du moins, des .so) dans le /usr/share. Autrement dit, je pense que ma méthode pour éviter les conflits de bibliothèques était maladroite.

Donc je me demandais : et si ça n'était pas plus simple si je mettais ces bibliothèques dans le répertoire /usr/lib/GNUstep ? Au moins, ld les prendrait en compte et je pourrais simplifier mes paquets, non ? :D
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10499
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par FoolEcho » dim. 04 mai 2014, 09:54

Xorg a écrit :Donc je me demandais : et si ça n'était pas plus simple si je mettais ces bibliothèques dans le répertoire /usr/lib/GNUstep ? Au moins, ld les prendrait en compte et je pourrais simplifier mes paquets, non ? :D
Peut-être oui (on a parfois tendance à prendre la solution de facilité de tout caser dans /usr/share ou /opt mais dans ton cas, ça ne me choque pas outre mesure puisqu'il suffit de faire l'export qui va bien).
Il faut voir ce qui ferait éventuellement conflit entre tes paquets et les dépôts (vu que gnustep et cie doit lui avoir recours à /usr/lib/GNUstep) et le spécifier dans ton PKGBUILD (donc éventuellement c'est un problème pour qui voudrait les deux en même temps puisqu'il semble que les deux ne sont pas équivalents :? ).
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » dim. 04 mai 2014, 12:07

Le conflit était juste avec libobjc.so quand je mettais les bibliothèques dans le /usr/lib (c'est le cas des paquets gnustep officiels d'ArchLinux) si je me rappelle bien.
De toute façon, dans l'état actuel des choses, la version de GNUstep que je propose sur AUR n'est pas compatible avec le reste (car les paquets fournissent les mêmes fichiers, c'est juste que ça n'utilise pas le même compilateur au final), j'avais déjà mis la version gnustep-clang-svn en conflit avec le reste.

Dans GNUstep, il faut savoir une chose, c'est qu'il y a la variable GNUSTEP_SYSTEM_LIBRARY (/usr/lib/GNUstep) et la variable GNUSTEP_SYSTEM_LIBRARIES (/usr/lib dans les paquets officiels, /usr/share/GNUstep/lib dans mes paquets).

Sauf que le /usr/lib/GNUstep est un peu particulier : que ça soit dans les paquets officiels ou dans les miens, il n'y a pas de bibliothèques (type .so) dedans ; en réalité, ce répertoire est constitué d'une multitude de sous-répertoires, qui contiennent eux-mêmes des bibliothèques, mais des bibliothèques particulières à GNUstep (par exemple, usr/lib/GNUstep/DTDs/gsdoc-0_6_5.dtd). Donc il n'y a pas de fichiers qui répondent au nom de /usr/lib/GNUstep/*.so. Alors ça signifie que rien ne m'empêche d'utiliser le répertoire /usr/lib/GNUstep pour mettre les bibliothèques dedans, vu que même si je l'appelais /usr/lib/gnustep-clang-svn, ça reviendrait au même à la fin.

Alors la nouvelle question serait plutôt : est-ce mal vu que les variables GNUSTEP_SYSTEM_LIBRARY et GNUSTEP_SYSTEM_LIBRARIES soient les mêmes (/usr/lib/GNUstep pour les deux) ? Si tel est le cas, je n'aurais pas trop de difficultés à modifier la variable GNUSTEP_SYSTEM_LIBRARIES pour qu'elle vaille /usr/lib/gnustep-clang-svn par exemple. Mais dans le cas contraire, ça me permettrait de mieux exploiter un répertoire qui existe déjà, au risque de provoquer une nouvelle confusion dans la compréhension de mes paquets. :?

Je te remercie encore pour ton aide, FoolEcho. :D
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10499
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par FoolEcho » dim. 04 mai 2014, 20:25

Xorg a écrit :Alors la nouvelle question serait plutôt : est-ce mal vu que les variables GNUSTEP_SYSTEM_LIBRARY et GNUSTEP_SYSTEM_LIBRARIES soient les mêmes (/usr/lib/GNUstep pour les deux) ? Si tel est le cas, je n'aurais pas trop de difficultés à modifier la variable GNUSTEP_SYSTEM_LIBRARIES pour qu'elle vaille /usr/lib/gnustep-clang-svn par exemple. Mais dans le cas contraire, ça me permettrait de mieux exploiter un répertoire qui existe déjà, au risque de provoquer une nouvelle confusion dans la compréhension de mes paquets. :?
Techniquement rien ne l'empêche... après il faut voir le détail de ces variables.
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » dim. 04 mai 2014, 21:00

http://www.gnustep.org/resources/documentation/Developer/Base/Reference a écrit :GNUSTEP_SYSTEM_LIBRARY
This is where System resources get installed. This directory will contain a lot of executable code since *step traditionally likes to bundle executables and resources together.
Traditionally it is /usr/GNUstep/System/Library.
GNUSTEP_SYSTEM_LIBRARIES
This is where System libraries get installed. By libraries we mean the shared/static object files that you can link into programs.
Traditionally it is /usr/GNUstep/System/Library/Libraries.
Si je fais ceci ;
GNUSTEP_SYSTEM_LIBRARY -> /usr/lib/GNUstep
GNUSTEP_SYSTEM_LIBRARIES -> /usr/lib/gnustep-clang-svn
Ça ne violerait pas la documentation au moins. Alors c'est certainement la décision la plus sage que je peux tenter.

Merci pour ton aide ! :D
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » mar. 06 mai 2014, 23:18

Ah, en fait ldconfig ne recherche pas dans les sous-répertoires de /usr/lib, donc mettre les bibliothèques dans /usr/lib/gnustep-clang-svn n'a pas fonctionné. :mrgreen:

La seule raison qui faisait que je m'étais autant compliqué la vie était la bibliothèque /usr/lib/libobjc.so de gcc-libs, qui est en conflit avec la libobjc.so de gnustep-libobjc2-clang-svn. Pourtant, dans gcc-libs, c'est un lien symbolique vers /usr/lib/libobjc.so.4.0.0, alors que dans gnustep-libobjc2-clang-svn, c'est un lien symbolique vers libobjc.so.4.6, donc les fichiers pointés par ces liens symboliques diffèrent.

Bref, la méthode "simple" consiste à installer normalement les bibliothèques de gnustep-clang-svn dans /usr/lib, et pour éviter le conflit avec /usr/lib/libobjc.so, je l'ai simplement supprimé de gnustep-libobjc2-clang-svn. Alors bien sûr, ça pose un problème pour les paquets qui vont utiliser /usr/lib/libobjc.so (-> /usr/lib/libobjc.so.4.0.0) s'ils ont en réalité besoin de /usr/lib/libobjc.so (-> /usr/lib/libobjc.so.4.6). Et pour résoudre cela, il suffit d'utiliser ce drapeau pendant la compilation : LDFLAGS="$LDFLAGS,-l:libobjc.so.4.6"

J'aurais préféré m'en rendre compte quelques mois plus tôt... :copain:
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux

Message par Xorg » sam. 17 janv. 2015, 12:54

Salut.

En même temps que ma migration vers aur-dev, j'en profite pour faire le tour de mes paquets, et je dois prendre une décision envers GNUstep-clang-svn et Darling.
Ce n'est pas pratique pour moi à maintenir les paquets en double (la version monolib et la version multilib), car au fond la version multilib est exactement la version monolib avec uniquement des ajouts dans le PKGBUILD pour les parties en 32 bits (et quelques changements mineurs dans les variables).
Je suis donc en train de réfléchir à un paquet splitté, qui comprendrait à la fois la version monolib et la version multilib. Voici un exemple pour le paquet gnustep-make-clang-svn :

Code : Tout sélectionner

_svnname=gnustep-make
pkgbase=$_svnname-clang-svn
pkgname=("$_svnname-clang-svn")
[[ $CARCH == "x86_64" ]] && pkgname+=("$_svnname-multilib-clang-svn")
pkgver=38296
pkgrel=1
pkgdesc="The GNUstep make package, using Clang"
arch=('any')
url="http://www.gnustep.org/"
license=('GPL3')
groups=('gnustep-clang-svn')
depends=('bash')
makedepends=('svn')
makedepends_i686=('gcc-libs>=4.9.0' 'clang')
makedepends_x86_64=('gcc-libs-multilib>=4.9.0' 'lib32-clang')
conflicts=('gnustep-make')
options=('!emptydirs')
source=("$_svnname::svn://svn.gna.org/svn/gnustep/tools/make/trunk/"
	'arch'
	'arch32')
md5sums=('SKIP'
         '0daa9a592d808306193540bda0980673'
         '2a6ac6a4b3feac708d3272829cfcdc37')

pkgver() {
	cd "$srcdir/$_svnname"
	svnversion | tr -d [A-z]
}

prepare() {
	if [[ $CARCH == "x86_64" ]]; then
		msg2 "Make a clone of $_svnname"
		cp -Rv "$srcdir/$_svnname" "$srcdir/$_svnname-32"
		cp -v "$srcdir/arch32" "$srcdir/$_svnname-32/FilesystemLayouts/"
	fi

	msg2 "Copy new file system layouts for Arch..."
	cp -v "$srcdir/arch" "$srcdir/$_svnname/FilesystemLayouts/"
}

build() {
	cd "$srcdir/$_svnname"
	msg2 "Run 'configure'..."
	CC="clang" CXX="clang++" ./configure --prefix=/usr --sysconfdir=/etc/GNUstep --with-layout=arch --with-objc-lib-flag=-l:libobjc.so.4.6

	if [[ $CARCH == "x86_64" ]]; then
		cd "$srcdir/$_svnname-32"
		export PKG_CONFIG_PATH="/usr/lib32/pkgconfig"
		msg2 "Run 'configure' (32-bit)..."
		CC="clang -m32" CXX="clang++ -m32" ./configure --prefix=/usr --libdir=/usr/lib32 --sysconfdir=/etc/GNUstep --with-layout=arch32 \
		--with-objc-lib-flag=-l:libobjc.so.4.6 --with-config-file=/etc/GNUstep/GNUstep32.conf
	fi
}

package_gnustep-make-clang-svn() {
	cd "$srcdir/$_svnname"
	msg2 "Install..."
	make DESTDIR="$pkgdir" install
	echo -e "# Added by $pkgname package\nexport PATH=$PATH" >> "$pkgdir/usr/share/GNUstep/Makefiles/GNUstep-reset.sh"
}

package_gnustep-make-multilib-clang-svn() {
	pkgdesc="The GNUstep make package for multilib, using Clang"
	arch=('x86_64')
	groups=('gnustep-multilib-clang-svn')
	conflitcs=('gnustep-make-clang-svn')
	provides=('gnustep-make-clang-svn')

	# 64-bit install
	package_gnustep-make-clang-svn

	# 32-bit install
	cd "$srcdir/$_svnname-32"
	msg2 "Install (32-bit)..."
	make DESTDIR="$pkgdir" install
	echo -e "# Added by $pkgname package\nexport PATH=$PATH" >> "$pkgdir/usr/share/GNUstep32/Makefiles/GNUstep-reset.sh"
}
Exemple car il faut certainement que je peaufine les dépendances.
Bref, cela fonctionne, mais du coup ça fait que sur x86_64 ça force l'installation de gcc-libs-multilib pour ceux qui utilise le paquet monolib x86_64 (en multilib, cela est le comportement voulu).

Est-ce que vous pensez que c'est problématique et qu'il faut que j'évite le split, ou bien est-ce que c'est bon pour le split ?

Merci d'avance. :)
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10499
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux

Message par FoolEcho » sam. 17 janv. 2015, 13:13

Je ne pense pas que ça pose problème (d'autant moins pour un outil supposé aussi faire tourner des applis 32 bits sur du 64, comme wine).
En tous cas, rien n'empêche de faire des paquets splittés de ce type à ma connaissance...

Qui peut le plus, peu le moins...
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux

Message par Xorg » sam. 17 janv. 2015, 13:23

Effectivement, c'est vrai pour Wine.

Très bien, merci pour la réponse rapide, je vais essayer comme ça alors (vu qu'il m'arrive d'oublier de répercuter des changements entre les deux paquets :oops: ).
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux

Message par Xorg » sam. 17 janv. 2015, 16:59

Je me heurte à un problème : makepkg -s ne lit pas les variables propres aux paquets splittés, comme depends=(), ce qui fait que ça n'installe pas les dépendances nécessaires avant l'installation, et donc la compilation échoue.

À la base, si j'avais créé des paquets multilib, c'était pour ressembler aux paquets de GCC (GCC 64 bits ne permet pas de compiler en 32 bits, c'est pour cela qu'il faut la version multilib).
Je sais que la version 64 bits de Wine offre par défaut le support du 32 et du 64 bits, mais le gros désavantage de la version multilib de Darling, c'est qu'elle est presque deux fois plus grosse que la version monolib en 64 bits : dépendances doublées, temps de compilation doublé, taille occupée sur le disque augmentée, d'où pourquoi j'avais laissé une version 64 bits qui n'inclue pas le support pour les applications 32 bits.
Il y a énormément de dépendances qui proviennent de AUR pour la version multilib, ce qui décourage beaucoup de personnes à l'utiliser visiblement (il suffit de regarder le peu de votes qu'obtiennent les paquets multilib face aux paquets monolib), c'est pour ça que je ne veux pas forcer le support 32 bits sur les Arch x86_64.

Du coup pour en revenir à mon problème, si je déclare depends_x86_64=() qui contient les dépendances propres à la version multilib en haut du PKGBUILD, ça va installer trop de dépendances inutiles dans le cas d'une installation monolib sur architecture x86_64, mais si je mets cette variables dans la fonction package_pkg-multilib(), cela n'a pas d'effet. :?

Je ne sais pas quoi faire. :mrgreen:
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10499
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux

Message par FoolEcho » sam. 17 janv. 2015, 19:49

Xorg a écrit :Du coup pour en revenir à mon problème, si je déclare depends_x86_64=() qui contient les dépendances propres à la version multilib en haut du PKGBUILD, ça va installer trop de dépendances inutiles dans le cas d'une installation monolib sur architecture x86_64, mais si je mets cette variables dans la fonction package_pkg-multilib(), cela n'a pas d'effet. :?

Je ne sais pas quoi faire. :mrgreen:
Je n'ai pas trop compris ton problème (je ne vois pas ce qui t'empêche de définir des dépendances globales et/ou modifier, rajouter ce qui va bien dans les fonctions package() de tes différentes composantes...)... et je ne vois pas pourquoi tu parles d'une installation monolib puisque tu ne le fais pas non plus, si j'ai suivi... :|

Montrer ton PKGBUILD en l'état serait plus éclairant, je pense...
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux

Message par Xorg » sam. 17 janv. 2015, 19:58

Effectivement, ça pourrait être plus efficace. :mrgreen:

Code : Tout sélectionner

_svnname=gnustep-base
pkgbase=$_svnname-clang-svn
pkgname=("$_svnname-clang-svn")
[[ $CARCH == "x86_64" ]] && pkgname+=("$_svnname-multilib-clang-svn")
epoch=1
pkgver=r38296
pkgrel=1
pkgdesc="The GNUstep base package, using Clang"
arch=('i686' 'x86_64')
url="http://www.gnustep.org/"
license=('GPL2' 'GPL3' 'LGPL2.1')
groups=('gnustep-clang-svn')
depends=('libffi' 'libxml2' 'libxslt' 'openssl' 'gnutls' 'icu' 'gnustep-libobjc2-clang-svn')
makedepends=('svn' 'gnustep-make-clang-svn')
makedepends_i686=('clang')
makedepends_x86_64=('lib32-clang')
optdepends=('iconv: only if you don`t have glibc'
	'ffcall: alternative for libffi'
	'avahi: enable NSNetServices support')
optdepends_i686=('libdispatch-clang-git: enable dispatching blocks via libdispatch')
optdepends_x86_64=('lib32-avahi: enable 32-bit NSNetServices support'
	'lib32-libdispatch-clang-git: enable dispatching blocks via libdispatch')
conflicts=('gnustep-base' 'gnustep-base-svn')
options=('!emptydirs')
source=("$_svnname::svn://svn.gna.org/svn/gnustep/libs/base/trunk/")
md5sums=('SKIP')

pkgver() {
	cd "$srcdir/$_svnname"
	local ver="$(svnversion)"
	printf "r%s" "${ver//[[:alpha:]]}"
}

prepare() {
	msg2 "Fix permissions..."
	sed -i 's/tar -xf $(TIMEZONE_ARCHIVE);/tar -xf $(TIMEZONE_ARCHIVE);chown -R root:root * ;/' "$srcdir/$_svnname/NSTimeZones/Makefile.postamble"

	if [[ $CARCH == "x86_64" ]]; then
		msg2 "Make a clone of $_svnname"
		cp -Rv "$srcdir/$_svnname" "$srcdir/$_svnname-32"
	fi
}

build() {
	cd "$srcdir/$_svnname"

	msg2 "Run 'configure'..."
	OBJCFLAGS="-fblocks" CC="clang" CXX="clang++" ./configure --prefix=/usr --sysconfdir=/etc/GNUstep \
		--disable-unicodeconstants --with-ffi-include=/usr/lib/libffi-`pacman -Q libffi | cut -f2 -d\ |cut -f1 -d-`/include/

	msg2 "Run 'make'..."
	make

	if [[ $CARCH == "x86_64" ]]; then
		# 32-bit build on x86_64
		cd "$srcdir/$_svnname-32"
		source "/usr/share/GNUstep32/Makefiles/GNUstep.sh"
		export PKG_CONFIG_PATH="/usr/lib32/pkgconfig"

		msg2 "Run 'configure' (32-bit)..."
		OBJCFLAGS="-fblocks" CC="clang -m32" CXX="clang++ -m32" ./configure --prefix=/usr --libdir=/usr/lib32 --sysconfdir=/etc/GNUstep \
			--disable-unicodeconstants --with-ffi-include=/usr/lib32/libffi-`pacman -Q lib32-libffi | cut -f2 -d\ |cut -f1 -d-`/include/

		msg2 "Run 'make' (32-bit)..."
		make
	fi
}

check() {
	cd "$srcdir/$_svnname"
	make check || true

	if [[ $CARCH == "x86_64" ]]; then
		# 32-bit check on x86_64
		cd "$srcdir/$_svnname-32"
		make check || true
	fi
}

package_gnustep-base-clang-svn() {
	cd "$srcdir/$_svnname"
	msg2 "Install..."
	make DESTDIR="$pkgdir" install
}

package_gnustep-base-multilib-clang-svn() {
	pkgdesc="The GNUstep base package for multilib, using Clang"
	arch=('x86_64')
	groups=('gnustep-multilib-clang-svn')
	depends_x86_64=('lib32-libffi' 'lib32-libxml2' 'lib32-libxslt' 'lib32-openssl' 'lib32-gnutls' 'lib32-icu' 'lib32-libao' 'gnustep-libobjc2-multilib-clang-svn')
	provides=('gnustep-base-clang-svn')
	conflicts+=('gnustep-base-clang-svn')

	# 64-bit install
	package_gnustep-base-clang-svn

	# 32-bit install on x86_64
	cd "$srcdir/$_svnname-32"
	msg2 "Install (32-bit)..."
	GNUSTEP_CONFIG_FILE="/etc/GNUstep/GNUstep32.conf" make DESTDIR="$pkgdir" install
}
Le problème quand je fais un makepkg -s, c'est que ça n'installe pas les dépendances définis dans la variable depends_x86_64= de la fonction package_gnustep-base-multilib-clang-svn().

J'étais en train de me dire en postant, peut-être qu'il faut que je fasse ceci :

Code : Tout sélectionner

[...]
depends=('libffi' 'libxml2' 'libxslt' 'openssl' 'gnutls' 'icu' 'gnustep-libobjc2-clang-svn')
depends_x86_64=('lib32-libffi' 'lib32-libxml2' 'lib32-libxslt' 'lib32-openssl' 'lib32-gnutls' 'lib32-icu' 'lib32-libao' 'gnustep-libobjc2-multilib-clang-svn')
makedepends=('svn' 'gnustep-make-clang-svn')
makedepends_i686=('clang')
makedepends_x86_64=('lib32-clang')
[...]

package_gnustep-base-clang-svn() {
	depends_x86_64=() # Rendre cette variable vide

	[...]
}

package_gnustep-base-multilib-clang-svn() {
	pkgdesc="The GNUstep base package for multilib, using Clang"
	arch=('x86_64')
	groups=('gnustep-multilib-clang-svn')

	[...]
}
Qu'en penses-tu ? :)
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10499
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux

Message par FoolEcho » dim. 18 janv. 2015, 12:39

À voir ce qui fonctionne... mais tu devrais trifouiller directement depends et non depends_x86_64 vu que la fonction package ne s'applique qu'à l'architecture x86_64 dans ce cas... (regarde encore une fois du côté du PKGBUILD de wine, je crois que ça joue sur une modification des dépendances ou non dans les différentes fonctions package)
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux

Message par Xorg » dim. 18 janv. 2015, 13:40

Oui, j'ai regardé, et j'ai vu que dans le paquet Wine que _depends=() contient les dépendances pour i686 et x86_64, et depends=() pour i686 contient _depends=() moins les paquets préfixés par lib32.

Encore une fois, Wine n'est pas un bon exemple pour Darling car Wine fournit le support 32 et 64 bits sur x86_64, or darling-git offre uniquement le support du 64 bits sur x86_64.
darling-multilib-git lui supporte les deux, mais vu le peu d'utilisateurs qui utilisent ce paquet, je n'ai pas l'impression que ça fasse l’unanimité, et c'est pour ça que je ne veux pas que ça la fasse "à la Wine".

En fait, peu importe que je mette depends=() ou depends_x86_64=() dans la fonction package_gnustep-base-multilib-clang-svn() car dans les deux cas, cette variable n'est pas lue lors de makepkg -s. Même avec makepkg -s --pkg gnustep-base-multilib-clang-svn ça ne fonctionne pas mieux.

Code : Tout sélectionner

_svnname=gnustep-base
pkgbase=$_svnname-clang-svn
pkgname=("$_svnname-clang-svn")
[[ $CARCH == "x86_64" ]] && pkgname+=("$_svnname-multilib-clang-svn")
epoch=1
pkgver=r38296
pkgrel=1
pkgdesc="The GNUstep base package, using Clang"
arch=('i686' 'x86_64')
url="http://www.gnustep.org/"
license=('GPL2' 'GPL3' 'LGPL2.1')
groups=('gnustep-clang-svn')
depends=('libffi' 'libxml2' 'libxslt' 'openssl' 'gnutls' 'icu' 'gnustep-libobjc2-clang-svn')
makedepends=('svn' 'gnustep-make-clang-svn')
makedepends_i686=('clang')
makedepends_x86_64=('lib32-clang')
optdepends=('iconv: only if you don`t have glibc'
	'ffcall: alternative for libffi'
	'avahi: enable NSNetServices support')
optdepends_i686=('libdispatch-clang-git: enable dispatching blocks via libdispatch')
optdepends_x86_64=('lib32-avahi: enable 32-bit NSNetServices support'
	'lib32-libdispatch-clang-git: enable dispatching blocks via libdispatch')
conflicts=('gnustep-base' 'gnustep-base-svn')
options=('!emptydirs')
source=("$_svnname::svn://svn.gna.org/svn/gnustep/libs/base/trunk/")
md5sums=('SKIP')

pkgver() {
	cd "$srcdir/$_svnname"
	local ver="$(svnversion)"
	printf "r%s" "${ver//[[:alpha:]]}"
}

prepare() {
	msg2 "Fix permissions..."
	sed -i 's/tar -xf $(TIMEZONE_ARCHIVE);/tar -xf $(TIMEZONE_ARCHIVE);chown -R root:root * ;/' "$srcdir/$_svnname/NSTimeZones/Makefile.postamble"

	if [[ $CARCH == "x86_64" ]]; then
		msg2 "Make a clone of $_svnname"
		cp -Rv "$srcdir/$_svnname" "$srcdir/$_svnname-32"
	fi
}

build() {
	cd "$srcdir/$_svnname"

	msg2 "Run 'configure'..."
	OBJCFLAGS="-fblocks" CC="clang" CXX="clang++" ./configure --prefix=/usr --sysconfdir=/etc/GNUstep \
		--disable-unicodeconstants --with-ffi-include=/usr/lib/libffi-`pacman -Q libffi | cut -f2 -d\ |cut -f1 -d-`/include/

	msg2 "Run 'make'..."
	make

	if [[ $CARCH == "x86_64" ]]; then
		# 32-bit build on x86_64
		cd "$srcdir/$_svnname-32"
		source "/usr/share/GNUstep32/Makefiles/GNUstep.sh"
		export PKG_CONFIG_PATH="/usr/lib32/pkgconfig"

		msg2 "Run 'configure' (32-bit)..."
		OBJCFLAGS="-fblocks" CC="clang -m32" CXX="clang++ -m32" ./configure --prefix=/usr --libdir=/usr/lib32 --sysconfdir=/etc/GNUstep \
			--disable-unicodeconstants --with-ffi-include=/usr/lib32/libffi-`pacman -Q lib32-libffi | cut -f2 -d\ |cut -f1 -d-`/include/

		msg2 "Run 'make' (32-bit)..."
		make
	fi
}

check() {
	cd "$srcdir/$_svnname"
	make check || true

	if [[ $CARCH == "x86_64" ]]; then
		# 32-bit check on x86_64
		cd "$srcdir/$_svnname-32"
		make check || true
	fi
}

package_gnustep-base-clang-svn() {
	cd "$srcdir/$_svnname"
	msg2 "Install..."
	make DESTDIR="$pkgdir" install
}

package_gnustep-base-multilib-clang-svn() {
	pkgdesc="The GNUstep base package for multilib, using Clang"
	arch=('x86_64')
	groups=('gnustep-multilib-clang-svn')
	depends=('lib32-libffi' 'lib32-libxml2' 'lib32-libxslt' 'lib32-openssl' 'lib32-gnutls' 'lib32-icu' 'lib32-libao' 'gnustep-libobjc2-multilib-clang-svn')
	provides=('gnustep-base-clang-svn')
	conflicts+=('gnustep-base-clang-svn')

	# 64-bit install
	package_gnustep-base-clang-svn

	# 32-bit install on x86_64
	cd "$srcdir/$_svnname-32"
	msg2 "Install (32-bit)..."
	GNUSTEP_CONFIG_FILE="/etc/GNUstep/GNUstep32.conf" make DESTDIR="$pkgdir" install
}
makepkg ne me permet pas de faire ce que je veux faire de toute façon. J'ai deux solutions : soit je vois avec les développeurs de Pacman, ou soit j'arrête cette idée stupide.

EDIT : Trouvé. Il semblerait que la deuxième solution soit envisageable...

EDT2 : Après mûre réflexion, cette idée était purement stupide vu qu'il n'est pas possible que la fonction build() se termine correctement si on cherche à installer le paquet gnustep-base-clang-svn sur x86_64. Donc je crois que je vais la faire "à la Wine" et virer la version de Darling qui supporte uniquement que le 64 bits. Merci pour ta patience FoolEcho. :)
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux

Message par Xorg » dim. 06 mars 2016, 19:13

Salut tout le monde (oh, ça fait déjà plus d'un an que je n'ai pas posté dans ce topic :roll: ).

Je viens donner quelques nouvelles du projet, qui a énormément évolué ces derniers mois. L'idée du développeur principal a été de repenser intégralement libSystem (voir Rethinking the libSystem approach), ce qui lui a valu une énorme quantité de travail, mais ça devrait rendre Darling plus robuste.
Darling est maintenant composé de plusieurs sous-modules, facilitant la gestion des dépendances (voir Darling Project sur GitHub).

Quelques changements intéressants pour les utilisateurs :
  • Ajout d'un $DPREFIX (similaire au $WINEPREFIX de Wine), par défaut ~/.darling (contre ~/.wine pour Wine)
  • Ajout d'une interface plus intuitive pour l'utilisateur (commande darling)
  • Ajout d'un shell basique (darling shell)
  • Gestion des paquets .pkg (avec la commande installer dans le shell de Darling)
  • Gestion des images disque .dmg (avec la commande hdiutil dans le shell de Darling)
Toutefois, quelques changements à noter : Darling nécessite un module noyau pour fonctionner correctement (darling-mach). De plus, il semble qu'il n'y ait plus de support pour les OS 32 bits, on peut compiler Darling uniquement sur processeur 64 bits (mais il reste possible d'exécuter des binaires OS X 32 bits).

Au niveau des paquets, il y a toujours darling-git sur AUR, et maintenant darling-mach-git (qui ne contient que le module, afin de faciliter la recompilation en cas de mise à jour du noyau). Je prévois une version DKMS du module dans un futur proche. :)

Si vous avez l'âme d'un testeur, d'un développeur, ou si vous avez simplement besoin de faire tourner un binaire pour Darwin/OS X sous Linux (oubliez les jeux vidéos et compagnie pour le moment), n'hésitez pas à voir du côté de Darling. :wink:
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Répondre