I changed the svn's version to work with git. The compilation and installation works well, but I'm not experienced and you can take a look. If you are interested the PKGBUILD is here :
http://pastebin.com/Fuswna50
Search Criteria
Package Details: freecad-git 0.22.0.36999.ged77603af9-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/freecad-git.git (read-only, click to copy) |
|---|---|
| Package Base: | freecad-git |
| Description: | A general purpose 3D CAD modeler - git checkout |
| Upstream URL: | https://www.freecad.org/ |
| Licenses: | LGPL |
| Conflicts: | freecad, freecad-appimage, freecad-appimage-git |
| Provides: | freecad |
| Submitter: | gborzi |
| Maintainer: | greyltc (adrianinsaval) |
| Last Packager: | adrianinsaval |
| Votes: | 106 |
| Popularity: | 0.75 |
| First Submitted: | 2012-03-03 13:46 (UTC) |
| Last Updated: | 2024-04-30 00:29 (UTC) |
Dependencies (39)
- boost-libs
- coin (coin-gitAUR)
- fmt (fmt-gitAUR)
- glew (glew-libepoxyAUR, glew-wayland-gitAUR, glew-gitAUR)
- jsoncpp (jsoncpp-cmake-gitAUR, jsoncpp-cmakeAUR, jsoncpp-gitAUR)
- medAUR (med-openmpi)
- netcdf (netcdf-openmpi)
- opencascade (opencascade-gitAUR)
- openmpi (openmpi-gitAUR)
- pyside6
- pyside6-tools
- python-matplotlib (python-matplotlib-gitAUR)
- python-packaging
- python-pivy
- python-ply
- python-yaml (python-yaml-gitAUR)
- qt6-5compat
- qt6-base (qt6-base-gitAUR, qt6-base-headlessAUR)
- qt6-svg
- qt6-tools
- Show 19 more dependencies...
Required by (4)
- freecad-a2plus-git (requires freecad)
- freecad-cadquery-git (requires freecad)
- freecad-fcgear-git (requires freecad)
- openmc-git (requires freecad)
Sources (1)
PerisH commented on 2012-02-29 20:31 (UTC)
gborzi commented on 2011-12-25 18:51 (UTC)
@mickele
I think they're using both systems. On svn the version now is 5348, up from 5330 of a couple of days ago.
mickele commented on 2011-12-25 18:38 (UTC)
It seems freecad switched to git:
http://sourceforge.net/scm/?type=git&group_id=49159
gborzi commented on 2011-12-01 17:36 (UTC)
@eworm
I think it would work, but when boost changes version I'll upload a new PKGBUILD anyway.
eworm commented on 2011-12-01 16:16 (UTC)
@gborzi
That's true... Something I suffer from time to time, especially with boost. ;)
Does something like this work?
_boostver=`pacman -Q boost-libs | cut -d\ -f2 | cut -d- -f1`
depends(boost-libs=${_boostver} ...)
This would give hard dependency in the binary package, but make it compile with whatever boost version is installed.
gborzi commented on 2011-12-01 16:01 (UTC)
@cgx
I'll try compiling with 1.48 this evening.
@eworm
Without the hard dep an upgrade to boost would break the package, a break that woudn't be noticed until one tries to launch the binary.
eworm commented on 2011-12-01 15:35 (UTC)
Uh, why does this have a hard dependency on boost?
Usually recompiling the package fixes the problem.
cgx commented on 2011-12-01 15:30 (UTC)
Any chance of compatability with boost-libs 1.48? It's in testing now
eworm commented on 2011-09-28 19:04 (UTC)
No problem. ;)
I do have my own build scripts that patch the PKGBUILD before the package is compiled. So I'm fine with it now. Thanks!
gborzi commented on 2011-09-28 16:38 (UTC)
@eworm
Up to now you are the only one with this problem, unless others report the same, I won't change the package. It is more probable that there is something in your setup that causes this problem, rather than an issue in the package.
Pinned Comments
adrianinsaval commented on 2023-03-12 14:50 (UTC)
If the check fails there is little I can do about it as it most likely needs to be fixed upstream, in such cases report those upstream (maybe wait a day or two as sometimes it's quickly solved upstream) or skip the check with
makepkg --nocheckif you don't care about the functionality that is being reported as failing in the check.