You are not logged in.
Hello, community!
I struggling with some sophisticated program package (writing PKGBUILD for it) which should be compiled for use. It is not using classic configure -- make -- make install scheme for building but rather modification of it (some kind of hand-written Makefile and configure script). The main problem that at the beginning of building process user should specify influental env variable which is used by install scripts. These scripts hard-code specified variable value into Python compiled modules (*.pyc), shared objects and different headers.
If I build software by hand in the needed destination directory (for example, /opt/softwarename), all is ok, but PKGBUILD building process involves fakeroot environment and if I specify ${srcdir}/softwarename as aforementioned env variable, value of that variable compiles-in binary Python modules, shared objects and headers. As for text files I can fix things up by sed utility in the package() function, but I can't do anything with binary files. As the consequence makepkg complains about references to the ${srcdir}/${pkgdir} and some modules doesn't work as expected. Setting up direct path for software (/opt/softwarename) doesn't work because makepkg has no access to these path by default.
So I stuck on this and don't know how to avoid such a problem. Could you advice something? Thank you!
Offline
Can you share or link this program and share your current PKGBUILD?
Offline
I can give only one part of this program (AmberTools17) because other part (AMBER16) is under restricted license and our research institute have bought it, but you can compile only the first part (the second is just the addition to the first; you can see my previous question about it here)
UPD: I can do it only tomorrow, because there is no link to the needed version on official website and I should upload it to somewhere.
UPD2: PKGBUILD is also on my lab computer so I can get it only tomorrow
UPD3: I've uploaded all needed files to my ftp server excluding license-restricted part. Also I've commented some lines in PKGBUILD which are responsible for building some parts of package because the problem described in the first post arises even for the simplest install
Last edited by dviktor (2018-09-12 08:25:41)
Offline
The general solution to this problem is that software should support the concept of "prefix", which is the path used to compile in paths, *separately* from $DESTDIR which is the path to prepend to all paths when copying files into the installation directory.
It sounds like you're using srcdir, inside the "prefix", and the software may not even support DESTDIR at all.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Yes, you're right. This software ignores DESTDIR completely but support --prefix concept. However, it treats prefix in own manner and tries directly create and write files here. Also because of their own makefile the contents of prefix is included in some files
Offline
Ouch, I'm looking at all this --prefix ${srcdir}/build and crying in sympathy.
Is it possible to use --prefix=/usr and *not* install the files, but manually cp them yourself?
Or, I guess you could do extensive patching of the makefiles. I haven't looked at them yet because the download is huge...
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I haven't tried manual copy method yet. Should note: when make install is issued, some more compiling occurs and only after that actual copy performs. Also I think that aforementioned binaries are built in the make stage so manual copy may be of little help.
Offline