On Sat, 03 Oct 2009 15:31:36 +0200 Stephan Raue <[email protected]> said:
> Am 03.10.2009 15:15, schrieb Carsten Haitzler (The Rasterman): > > > > he doesn't need a solution. beyond having simply written bad install > > scripts of his own which makes it his own bug/problem. :) > i need a solution. if i change my arch ( i can do this with one > variable) i must adapt the installation path in my scripts. this is not that's what the makefiles already do. that arch/os dir is figured out at configure time thus being unique to the compile target. replacing e's install means you're going to have to extract whatever the configure script figures out into your scripts. i still don't see why you need/want/have to do your own install script. > a big problem for me, but if i dont know this i have problems. > when i am using svn versions and i update to a more recent version or i > update a released version then i have no control if the version in the > directoryname has changed. correct. these version names, arch names etc. are there for a good reason. it's to stop people from shooting themselves in their own feet and accidentally using a module from an older install with a new lib build if that module is now disabled. it's also to prevent changes in arch bleeding over and to be consistent with home directory modules. if you have a ~/.evas/modules dir - then this dir will be used like the PREFIX/lib/evas/modules dir - and used INSTEAD of the system one (it takes preference. this allows a user to build their own modules and add to/override the system ones evas ships with. but this requires they be built for the exact same version of evas and same architecture/os. thus that dir. > > i don't see a good reason to not > > use the make install. it's used in packaging for multiple distros - it can > > install anywhere you like.. using DESTDIR is a standard way to do this. i > > don't see a very good reason to do your own manual install scripts. :) > > > > > this is needed for making an embedded distro. on an embedded distro > development files (*.la), static libs (*.la), docu and manfiles are not > needed. it is easyer to copy some libs to the target then delete 50 > other files from target. and you have the full control which files are > on the target. this does every embedded distro (buildroot, geexbox, ...) well not others. debian embedded openembedded dont go writign their own install scripts. this is where i tell you: "you're doing it wrong". :) really if this is how you package/install all your software on your distro... you're in trouble. any well done autoconf/automake rtc. using software will work with the following generic rules: 1. use DESTDIR. i.e make DESTDIR=/tmp/mypackage install change /tmp/mypackage to be unique per package/thing you are building. (eg /tmp/evas, /tmp/glibc, /tmp/xorg etc.). make sure ths is a new empty directory before install - rm -rf it and mkdir -p it freshly so it is empty 2. now that you installed EVERYTHING into that 1 piece of clean directory tree, it can't be polluted with old files or fiels from any other package/compile/install so it's CLEAN. 3. NOW either choose to do things the "lazy way" and that is putting the entire compile contents into 1 package (generally a bad idea. you almost ALWAYS want to split 1 install into multiple packages. eg a core evas lib, then a "dev" package for development (.a files, .la files, .pc piles, .h headers etc.) not to mention evas is very much designed to be modular. it is in fact INTENDED to be split into sub-packages like a core evas lib, a package for each module and then use recommends/depends lines to suck in core dependencies or add more modules as specific applications need certain modules (loaders, engines etc.) thus limiting your ultimate install to ONLY what you need via dependencies of the final target apps. you can happily compile evas with every engine and loader possible and then only install modules for a subset of this allowing minimum install and maximum flexibility. 3.1 the "right way" should now be a list of files to put into specific packages (lets call them tarballs now with some form of header attached that gives you package name, version, dependencies, arch etc.). do what all the good packaging systems do.. use glob PATHS like this that use globs and variable substituion before determining all final paths. all paths are RELATIVE to DESTDIR (/tmp/evas for example) i.e. lib/blah/xxx really takes /tmp/evas/lib/blah/xxx: libevas files: $prefix/lib*/libevas*.so.* libevas-dev files: $prefix/lib*/pkgconfig/evas.pc $prefix/lib*/libevas*.so $prefix/lib*/libevas.a $prefix/lib*/libevas.la $prefix/include/* libevas-module-engine-software-generic files: $prefix/lib/evas/modules/engines/software_generic/*/module.so libevas-module-engine-software-x11 files: $prefix/lib/evas/modules/engines/software_x11/*/module.so ... and so on per package. even better is if your scripts keep a list of all files put into each sub-package, double-check you dont include the same file twice in 2 packages (complain/error out if you do) and that after packaging you see if any files/dirs are left that are not included in packages and warn about missing unpackaged files. you can add an ignore section like: ignore *.la *.a $prefic/lib*/xxx to ignore certain file (types) or paths in warning about unpackaged files. if you do the above, you will be packaging CORRECTLY. if you tell me your "embedded distribtuion" doesn't use packages, i'll also say you're wrong. you absolutely SHOULD use packages. at the absolute LEAST should use them to store the compile results of building an app/lib/whatever and then start a CLEAN rootfs and piece it together by unpacking such previously stored compile result tarballs.even then the argument that "storing packaging information" takes up too much space i believe is pointless in this day and age. any device you are putting efl on has enough space to also handle packaging. just look at a leaner packaging system. you still should have one so you can audit running systems to see if they have been modified, and how etc. and so you can upgrade things when bugs are found and fixed without a whole "reflash" of everyrthing just because you found glibc has a security buffer overflow bug? just upgrade glibc. thus the need for packages. anyway. see the above. that is the right way to package up software. not writing your own manual install scripts. debian doesnt do that (.deb packages). redhat doesnt do this (rpm packages). openembedded doesn't do that .opk/.ipk packages). noe one i know who does proper packaging feels a need to write their own install scripts. they install in destdirs and then cherrypick out of that install what they need with proper path globbing etc. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
