On Fri, 3 May 2024 22:29:00 +0200 Phil Otken <phil.ot...@gmail.com> said:
> After a rebuild of the OS, I compiled EFL successfully. Rather than run the > > sudo ninja -C build install > > command, I'd like to package it in an RPM. I can see where all the > libraries are, so creating the *efl.rpm* appears straightforward. OTOH, to > compile e, terminology, etc., I believe I also need to create > *efl-devel.rpm* as well. > > I believe all the header files, *.h need to go into the rpm; the question I > have is, are there any other files I need to include in the devel package? Well EFL (and e) etc. stick to a very standard set of installation locations. in fact they are pretty religious about adhering to the prefix given. so first to make a "standard" package you should provide --prefix=/usr when configuring efl and e with meson. This is what all standard packages do on every distro. they may also do a few other things like --sysconfdir=/etc but that's normally about it. this above has nothing to do with efl or e - it's just standard stuff. you might want to check the meson_options.txt. also i'm the arch linux maintainer for efl and e and others so you might want to look what the arch packages do options-wise as a guide to what is probably the right thing to do. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=efl-git https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=enlightenment-git there are others like rage, ecrire etc. - these build from git latest so stay as up to date as possible, and these are the latest stable releases: https://gitlab.archlinux.org/archlinux/packaging/packages/efl/-/blob/main/PKGBUILD?ref_type=heads https://gitlab.archlinux.org/archlinux/packaging/packages/enlightenment/-/blob/main/PKGBUILD?ref_type=heads now arch linux differs to rh/fedora/debian/ubuntu/suse etc. in that arch does NOT split out to -dev/-devel packages. generally arch does not split packages. you install something - it comes with all the headers and what not. it's a policy thing. now what goes into a dev/devel package? you got it right that .h files nee d to go - also for eina .x files. in fact just put everything in /usr/include/* that the package installs (the way most package build tools work is they use a DESTDIR to install into like /tmp/mypackage and then this dir ONLY holds things the package installed. thus you can blindly package up entire directories knowing nothing from the host fs will be in there). so go for /usr/include/* rather than .h files specifically. you will ALSO want to package /usr/lib/pkgconfig/* (always *.pc files in there). beware that it might be policy that pkgconfig is in /usr/lib64/pkgconfig or maybe its in /usr/lib/x86_64-linux-gnu/pkgconfig - i.e. some architecture triplet string parent enforced by your distro - so check this. *.pc files are used by pkgconfig to figure out how to compile against some library - they are used in conjunction with the *.h files for development. now something else policy-wise on your style of distro. *.so files in /usr/lib (or lib64 or lib/archstring) belong in dev/devel packages. this is different to the *.so.xx.yy.zz versioned files. so files that are libxxx.so are symlinks pointing to the latest major version and are used only for compiling. they are not needed for regular user "runtime use". so e.g. libevas.so needs to go into the dev(el) pkg. libevas.so. 1.27.0, libevas.so.1 go into the regular package. be aware that efl and e also have modules that are loaded at runtime to isolate extensions/features into their own binary shared libs. you will find these in /usr/lib/xxx/ e.g. /usr/lib/evas and a module .so file may be buried deep down a tree like /usr/lib/evas/modules/engines/gl_x11/v-1.27/module.so - these files in these lib dirs for efl are not for development. they are runtime. efl handles versioning them for you (as you can see above). same for enlightenment e.g. /usr/lib/enlightenment/modules/clock/linux-gnu-x86_64-0.26.0/module.so - but e also includes an arch triple because e also allows modules to load from ~/.e/e/modules (users can install their own without root access). as a home dir can be shared between different os's and arch's (nfs, rsync etc.) e also handles the arch triple. but all these modules belong in the core pkg and not the dev(el) packages. another thing to note - one reason for modules is to allow packages to split out dependencies. efl really would LIKE to build with all things enabled, but then allow packages to e.g. split out the heif image loader as that pulls in libheif as a dependency for a fairly rarely seen image format. so you could split out /usr/lib/evas/modules/image_loaders/heif (and everything below it) into a special efl-image-load-format-heif package. there are also image savers and engines. you could drop gl support as a dependency by splitting out all the gl engines in evas and ecore_evas into a efl-render-gl support package. you COULD also build efl twice and build 2 sets of gl support packages - build once with the default egl/gles and another time with glx. glx will not work with wayland but it works around some nvidia driver performance bugs that it has in egl/gles. no other drivers suffer from this thus i'm pretty much unmotivated to try have efl handle this for you (nvidia's binary blobs and what not). efl could actually in theory split out x11 and wayland support too into such split out packages if elementary moved its wl and x11 support into modules too, but due to this you can't effectively do that. you cans plit out other things too like the sample background set enlightenment comes in. i'd not recommend splitting out enlightenment modules as they don't pull in hard dependencies (like libraries). any deps are soft (eg bluez5 module needs bluez5 to work - but it'll soft fail and give you a ? gadget icon if it can't talk to bluez ... ). e and efl are actually very very very very packager friendly. they are built to follow standards as you'd expect and be easily able to be split up if you know what efl, e etc. do and what the modules, tools and dependencies do/mean. the work of splitting has already been done for you in the install of efl - you can take advantage of it in packaging where sensible. of course excessively splitting package-wise comes with problems. you may find functionality degrades if someone forgets to install and optional dep and they may not be smart/experienced enough to realize why that heif image doesn't load (they forgot to install the heif loader package). you might want to make convenience packages like efl-devel-all (if you end up splitting ever lib into its own package - i don't recommend splitting efl itself - while it is technically possible to have e.g. eina separate from emile and separate from evas and set up all the dependencies .. it's almost pointless as efl in all of its real use cases goes all the way up to the higher level libs like elementary which end up pulling in everything below it). i've even mulled merging efl into a single libefl.so for everything. any "optionalizing" of things would be handled by efl itself with modules ... in fact over time i now prefer the idea of just directly dlopening the dependency (like libheif) and doing my own symbol resolving as it means efl can build with all support and then at runtime find the dependencies and support itself. i hope that helps shed some light on this :) > -- > Thanks, > - Phil > > Phil Otken > Overlogix, Inc. <https://overlogix.com/> > also d.b.a. > Practical Software and Database Engineering, Inc. > c: +41 79 376 08 96 > e-mail: phil.ot...@gmail.com > Online Professional Profile: http://www.linkedin.com/in/potken/ > > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
