[AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux
- FoolEcho
- Maître du Kyudo
- Messages : 10707
- Inscription : dim. 15 août 2010, 11:48
- Localisation : Basse-Normandie
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L
Oui, c'est clairement plus élégant à présent.
«The following statement is not true. The previous statement is true.»
- Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L
D'accord. On y est arrivé !
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.
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.
- Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L
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...
- FoolEcho
- Maître du Kyudo
- Messages : 10707
- Inscription : dim. 15 août 2010, 11:48
- Localisation : Basse-Normandie
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L
Pour la beauté du geste.
Ça ne me surprend pas du fait de la complexité de la compilation déjà, ce n'est guère maintenable. À voir.
Ç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.»
- Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L
Bonsoir.
Je viens de réaliser qu'avec
En effet, si par exemple je créé un fichier /etc/ld.so.conf.d/gnustep.conf qui contiendrait par exemple ceci :
Alors dans ce cas là,
Ni d'utiliser LDFLAGS, comme par exemple :
Mais je n'ai pas l'impression que
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,
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
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
Code : Tout sélectionner
LDFLAGS="-L/usr/share/GNUstep/lib -L/usr/lib"
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 ? - FoolEcho
- Maître du Kyudo
- Messages : 10707
- Inscription : dim. 15 août 2010, 11:48
- Localisation : Basse-Normandie
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L
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).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 ?
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.»
- Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L
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.
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.
- FoolEcho
- Maître du Kyudo
- Messages : 10707
- Inscription : dim. 15 août 2010, 11:48
- Localisation : Basse-Normandie
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L
Techniquement rien ne l'empêche... après il faut voir le détail de ces variables.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.
«The following statement is not true. The previous statement is true.»
- Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L
Si je fais ceci ;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.
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 !
- Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L
Ah, en fait
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 :
J'aurais préféré m'en rendre compte quelques mois plus tôt...
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é. 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...
- Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux
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 :
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.
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"
}
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.
- FoolEcho
- Maître du Kyudo
- Messages : 10707
- Inscription : dim. 15 août 2010, 11:48
- Localisation : Basse-Normandie
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux
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...
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.»
- Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux
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 ).
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 ).
- Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux
Je me heurte à un problème :
À 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
Je ne sais pas quoi faire.
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.
- FoolEcho
- Maître du Kyudo
- Messages : 10707
- Inscription : dim. 15 août 2010, 11:48
- Localisation : Basse-Normandie
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux
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...Xorg a écrit :Du coup pour en revenir à mon problème, si je déclaredepends_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 fonctionpackage_pkg-multilib()
, cela n'a pas d'effet.
Je ne sais pas quoi faire.
Montrer ton PKGBUILD en l'état serait plus éclairant, je pense...
«The following statement is not true. The previous statement is true.»
- Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux
Effectivement, ça pourrait être plus efficace.
Le problème quand je fais un
J'étais en train de me dire en postant, peut-être qu'il faut que je fasse ceci :
Qu'en penses-tu ?
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
}
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')
[...]
}
- FoolEcho
- Maître du Kyudo
- Messages : 10707
- Inscription : dim. 15 août 2010, 11:48
- Localisation : Basse-Normandie
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux
À 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.»
- Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux
Oui, j'ai regardé, et j'ai vu que dans le paquet Wine que
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
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
_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. - Xorg
- Maître du Kyudo
- Messages : 1933
- Inscription : dim. 22 janv. 2012, 19:25
- Localisation : Entre le clavier et la chaise.
Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux
Salut tout le monde (oh, ça fait déjà plus d'un an que je n'ai pas posté dans ce topic ).
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 :
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.
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)
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.