SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I would imagine a developer might want to see and test things for him/herself and a simple script might be beneficial to aiding them. Newer features might be beneficial even to some and some extras for llvm often require, since they are git/svn sources, the most recent code from llvm.
(Is there a benefit in running a more recent llvm version? I get why someone would run mesa-git but what about llvm? Just asking out of curiosity. )
If you got amd hardware and use open drivers then you might need to update llvm before you update mesa to get the most out of your hardware.
If anyone wants a script for it then start by writing the script and then you may try to get it included and show that there's use for it, and the ones that like to use the script could use it even if it's included or not.
Hey Patrick, is there anyway we could get a simple script for llvm, like mesa, that fetches the latest git/svn edition in the /source?
If you just want to get latest llvm/git without any extras like compiler-rt or frontends... i have a lot of self-made buildscripts for various packages that will fetch latest git (or a specific git-commit). I just modified a sample to get latest llvm from a github-mirror:
Code:
#!/bin/sh
CWD=$(pwd)
# This is the username for the github project.
GITUSER=llvm-mirror
# This is the repository name on github.
GITPROJECT=llvm
# Get the commit history.
echo "Retrieving latest llvm/git commit..."
wget -O ${CWD}/tmp -q https://github.com/${GITUSER}/${GITPROJECT}/commits/master
# Get the date of last commit.
PACKAGE_RELEASE_DATE_GIT=`grep -m1 "time datetime" ${CWD}/tmp | sed "s,.*datetime=\",,g" | sed "s,T.*,,g" | sed "s,-,,g" | sed "s,^20,,g"`
# Get the commit id.
PACKAGE_RELEASE_REV_GIT=`grep -m1 "a href=.*/commits/" ${CWD}/tmp | sed "s,.*/commits/,,g" | sed "s,\".*,,g"`
# Remove the temporary stuff...
rm ${CWD}/tmp
# Name of the archive to create...
PACKAGE_SOURCE_NAME=llvm-${PACKAGE_RELEASE_DATE_GIT}git${PACKAGE_RELEASE_REV_GIT:0:7}.tar.gz
# Already there?
if ! test -f ${PACKAGE_SOURCE_NAME}; then
# Get latest git...
wget -O ${PACKAGE_SOURCE_NAME} \
https://github.com/${GITUSER}/${GITPROJECT}/tarball/$PACKAGE_RELEASE_REV_GIT
echo
echo "LLVM git/master with HEAD at ${PACKAGE_RELEASE_REV_GIT} packaged as ${PACKAGE_SOURCE_NAME}"
echo
else
# latest git already there...
echo
echo "Nothing to download."
echo "LLVM git/master with HEAD at ${PACKAGE_RELEASE_REV_GIT} already packaged as ${PACKAGE_SOURCE_NAME}"
echo
fi
For LLVM and/or MESA from git... it may compile or not
I found a minor issue while working on a python3 version of python-setuptools. It isn't copying any of the documentation over because no .txt files exist in the source. Quick patch available below.
One (possibly final one)... I already requested this earlier, and I don't know if it was missed or just decided against. For those who sometimes install into /usr/local, the packagename.pc file might be put in /usr/local/share/pkgconfig instead of /usr/local/lib{64}/pkgconfig. I know this is the case with compiz-bcop. This can cause ./configure to not detect the package without overriding the PKG_CONFIG_PATH to include the extra location. After a bit of thought, I decided it'd probably be best to just add the extra location to PKG_CONFIG_PATH rather than symlink /usr/local/lib64/pkgconfig and /usr/local/share/pkgconfig like is done in /usr, just in case files already exist in /usr/local/share/pkgconfig.
In case it was missed and not ignored, here's a patch for 64bit:
After a bit of thought, I decided it'd probably be best to just add the extra location to PKG_CONFIG_PATH rather than symlink /usr/local/lib64/pkgconfig and /usr/local/share/pkgconfig like is done in /usr, just in case files already exist in /usr/local/share/pkgconfig.
Seems safe enough. One point though -- /usr/lib{,64}/pkgconfig and /usr/share/pkgconfig have not been symlinked in quite some time, and the install script is supposed to break the link and properly sort the files if it finds the link. Can you check if the link is gone on your machine? If it isn't (and you have the latest pkg-config package) it's a bug.
One point though -- /usr/lib{,64}/pkgconfig and /usr/share/pkgconfig have not been symlinked in quite some time, and the install script is supposed to break the link and properly sort the files if it finds the link. Can you check if the link is gone on your machine? If it isn't (and you have the latest pkg-config package) it's a bug.
That's what I get for not paying good enough attention and doing stuff on both 14.1 and -current machines. My 14.1 machine is symlinked, but all -current installs are separate. Sorry for the confusion on that...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.