| Age | Commit message (Collapse) | Author |
|---|
|
NOTE: It was noted on the packaging guidelines for CMake based packages that
sometimes upstream can set specific flags only to be defined for certain build
types, like release for example.
So caution should be exercised by using the reccomended
'-DCMAKE_BUILD_TYPE=none' option.
|
|
|
|
|
|
This should be less prone to failiure and is just generally cleaner
Co-authored-by: Filipe Verri <filipeverri@gmail.com>
|
|
This was how it was before it recently got changed and was reported as broken by
an AUR comment (found incidentally by me too).
The issue was simply not being able to find 'libstandardese.so' and
'libcppast.so' when running the executable.
The change seems to somewhat of an issue upstream and is largely redundant and I
specutlate might not be worth the effort until the situation is improved
upstream.
As far as I can tell, there is few if any projects that use the
'libstandardese.so', and if they do, they should need the headers anyway, which
isn't provided by the 'make install', and it might be out of the scope of the
PKGBUILD to do such a thing unless there is a good reason for it, considering
any user would need to go upstream to get their headers until then even if it
were attempted to be fixed.
Also 'libcppast.so' is required but its a niche project and really has no reason
yet to be a shared library. Considering the above it makes sense to just link
it together.
Bumped the 'pkgrel' to indicate this change that should be a fix
|
|
|
|
'cmark' does not appear to ever be used or needed after building, so leaving it
as a runtime dependency doesn't really make sense.
Bump 'pkgrel' and 'pkgver' to mark potentially breaking changes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|