You are not logged in.

#1 2021-05-04 07:36:59

DAC324
Member
Registered: 2020-03-12
Posts: 80

Makepkg: Run prepare() without extracting sources

Hello all,

I must admit that I do not fully understand why this topic is of so little interest that Google retrieves forum threads with their last responses dating back to 2017 (and thus, causing complaints about "necrobumping" when trying to reply to them).

The question is: How can you avoid having to extract the source archive of a certain package again and again each time you make a modification to PKGBUILD to, let's say, include or exclude some flags or patches?

The -e option in makepkg skips both source extraction as well as running prepare() from PKGBUILD.

There was one recommendation to just execute prepare() from the command line:

. ./PKGBUILD
prepare

Or, better, sourcing the makepkg config file as well as the srcdir variable:

. /etc/makepkg.conf
. ./PKGBUILD
srcdir=$(readlink -f src)
prepare 

The recommendation was to put that in an alias like this:

alias runprep='. /etc/makepkg.conf && . ./PKGBUILD && srcdir=$(readlink -f src) && prepare'

That, indeed, seems to work to some extent, but I get error messages like

msg2: command not found
check_option: command not found

How can I include such commands like msg2 when running prepare() using the approach proposed above? Or is this impossible if commands like check_option or check_buildoption are used which seem to be makepkg internal commands?

Last edited by DAC324 (2021-05-04 07:50:23)

Offline

#2 2021-05-04 09:10:01

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
Website

Re: Makepkg: Run prepare() without extracting sources

Better question is why are you using makepkg internal options that are not documented and could change or be removed next release?

Offline

#3 2021-05-04 22:43:34

thiagowfx
Member
Registered: 2013-07-09
Posts: 586

Re: Makepkg: Run prepare() without extracting sources

https://wiki.archlinux.org/title/Arch_p … _etiquette:

Do not use makepkg subroutines (e.g. error, msg, msg2, plain, warning) as they might change at any time. To print data, use printf or echo.

Offline

#4 2021-05-05 13:29:23

DAC324
Member
Registered: 2020-03-12
Posts: 80

Re: Makepkg: Run prepare() without extracting sources

Allan wrote:

Better question is why are you using makepkg internal options that are not documented and could change or be removed next release?

I must admit that I did not write the PKGBUILD file by myself.

Thank you very much for pointing out that these internal options shall be avoided. I fully get that point. Problem now is: How can I replace them by something more reliable?

In particular, there are the following internal commands that need to be replaced:

check_option
check_buildoption

msg2 can be successfully replaced by echo so that is not a problem. But with the others, I currently do not have a clue.

Offline

#5 2021-05-05 13:51:52

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

Re: Makepkg: Run prepare() without extracting sources

If you want help fixing the PKGBUILD, you'll need to show us the PKGBUILD.

Those commands should simply be removed from the PKGBUILD.  If they were doing something important, then we need to know what their intent was.  The only way to fully replicate the exact functions from makepkg would be to use the actual functions from makepkg - but this is definitely not necessary.  So what *is* needed?

EDIT: based on your history - I'd guess this was all about chromium-dev, right?

For the ccache check (on line 531), there may be a better way, but you can just check for the CCACHE environment variables (e.g., CCACHE_PREFIX).  That's only if the check is even needed.  In at least one place (line 457) the check is pointless.  That if block sets a couple CCACHE_* environment variables if ccache is being used.  If it isn't being used, then there should be no harm in setting those variables anyways.  So don't even bother checking, just set the variables.  The check_option used for 'strip' seems equally useless: if strip is set, no symbols are used ... so what?  They'd be stripped anyways.  So this too does nothing.

I'd say toss that whole PKGBUILD and start from scratch.  It's needlessly complex and does a few things that are just silly but harmless, and so I'd bet it also does other things that are silly and potentially harmful (like lines 463-467).

Last edited by Trilby (2021-05-05 14:06:58)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#6 2021-05-05 13:52:56

a821
Member
Registered: 2012-10-31
Posts: 381

Re: Makepkg: Run prepare() without extracting sources

Can you post the PKGBUILD and tell us what you would like to change?

Offline

#7 2021-05-05 14:30:29

DAC324
Member
Registered: 2020-03-12
Posts: 80

Re: Makepkg: Run prepare() without extracting sources

Trilby wrote:

If you want help fixing the PKGBUILD, you'll need to show us the PKGBUILD.

Those commands should simply be removed from the PKGBUILD.  If they were doing something important, then we need to know what their intent was.  The only way to fully replicate the exact functions from makepkg would be to use the actual functions from makepkg - but this is definitely not necessary.  So what *is* needed?

EDIT: based on your history - I'd guess this was all about chromium-dev, right?

For the ccache check (on line 531), there may be a better way, but you can just check for the CCACHE environment variables (e.g., CCACHE_PREFIX).  That's only if the check is even needed.  In at least one place (line 457) the check is pointless.  That if block sets a couple CCACHE_* environment variables if ccache is being used.  If it isn't being used, then there should be no harm in setting those variables anyways.  So don't even bother checking, just set the variables.  The check_option used for 'strip' seems equally useless: if strip is set, no symbols are used ... so what?  They'd be stripped anyways.  So this too does nothing.

I'd say toss that whole PKGBUILD and start from scratch.  It's needlessly complex and does a few things that are just silly but harmless, and so I'd bet it also does other things that are silly and potentially harmful (like lines 463-467).

Indeed, I am playing around a bit with chromium-dev. In order to obtain the latest available version of the sources, I have found https://gsdview.appspot.com/chromium-br … a.tar.x%40 (where you can insert the latest version number available to you, in order to see if there are newer versions available already).

So I inserted these version numbers in chromium-dev's PKGBUILD in order to kind of automate the download and compilation of the latest Chromium developer build.

There are, of course, changes to be made to PKGBUILD from time to time, in order to keep up with the sources, such as inclusion or exclusion of third party components, patches and so on.
For that, it is, of course, not always necessary to extract the source archive freshly. As this takes a considerable amount of time on my old rig, I wanted to avoid that whenever possible.

That's the story, and here's the PKGBUILD I hacked together so far:

https://pastebin.com/pUCxBz6V

Offline

#8 2021-05-05 18:19:19

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Makepkg: Run prepare() without extracting sources

So, this is:

  • pointlessly checking for ccache before setting ccache-specific variables

  • pointlessly checking for strip before declining to generate the symbols which would be stripped anyway

  • checking for ccache and sed'ing ccache into the build scripts

  • not using the system clang (why not???)

  • disrespecting MAKEFLAGS from makepkg.conf when building bundled ffmpeg

  • forcing strip off, then manually stripping everything


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#9 2021-05-10 15:56:48

DAC324
Member
Registered: 2020-03-12
Posts: 80

Re: Makepkg: Run prepare() without extracting sources

eschwartz wrote:

So, this is:

  • pointlessly checking for ccache before setting ccache-specific variables

  • pointlessly checking for strip before declining to generate the symbols which would be stripped anyway

  • checking for ccache and sed'ing ccache into the build scripts

  • not using the system clang (why not???)

  • disrespecting MAKEFLAGS from makepkg.conf when building bundled ffmpeg

  • forcing strip off, then manually stripping everything

At least, I made some progress - the reason for not using system clang, llvm-ar, ld and others is that:

  • system clang does not know about plugins   "-Xclang",   "find-bad-constructs",   "-plugin-arg-find-bad-constructs",   "checked-ptr-as-trivial-member".

  • system ld does not know the option '--icf=' in general and '--icf=all' in particular

In order to circumvent this and to not having to patch the sources on each new version, the package maintainers chose to use the bundled buildtools instead of the system ones.

EDIT: At least for the first item, there is 'clang_use_chrome_plugins=false' that makes clang ignore those Chrome plugins.
Now, it looks like I must find out why "use_gold=false' and 'use_lld=false' do not seem to have any effect (options --color-diagnostics, --icf, and --no-call-graph-profile-sort are not recognized by lld).

And, even with the plugins removed, clang++ produces more fun when you try to use the system's version:

In file included from ../../base/check_op.h:11:
../../base/check.h:88:3: error: 'nomerge' attribute cannot be applied to a declaration
  NOMERGE ~CheckError();
  ^       ~
../../base/compiler_specific.h:344:19: note: expanded from macro 'NOMERGE'
#define NOMERGE [[clang::nomerge]]
                  ^
1 error generated.

Looks like using system buildtools, is not a good idea, at least for Chromium sad

Last edited by DAC324 (2021-05-10 19:42:00)

Offline

#10 2021-05-10 18:57:03

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Makepkg: Run prepare() without extracting sources

Gosh, I wish the Arch Developer who maintains the "chromium" package in [extra] and uses lld, clang_use_chrome_plugins=false, etc. was as smart as this random AUR user who somehow knows that chromium-dev is "easier" to build using the bundled buildtools...

... assuming by "easier" you mean "make a much bigger PKGBUILD that does all sorts of wild stuff that breaks the recommendation you mentioned in the first post".

How about we all agree the AUR maintainer is doing it wrong and should follow closer to [extra]/chromium? smile


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#11 2021-05-10 19:50:25

DAC324
Member
Registered: 2020-03-12
Posts: 80

Re: Makepkg: Run prepare() without extracting sources

eschwartz wrote:

Gosh, I wish the Arch Developer who maintains the "chromium" package in [extra] and uses lld, clang_use_chrome_plugins=false, etc. was as smart as this random AUR user who somehow knows that chromium-dev is "easier" to build using the bundled buildtools...

... assuming by "easier" you mean "make a much bigger PKGBUILD that does all sorts of wild stuff that breaks the recommendation you mentioned in the first post".

How about we all agree the AUR maintainer is doing it wrong and should follow closer to [extra]/chromium? smile

Thank you very much for your wisdom.

The PKGBUILD I had linked to, was not entirely created by me (apologies if that wasn't clear). I only tried to adapt it to newer versions of the source code.

At least, I was just trying to follow your recommendations but apparently failed.

Plus, the idea for using the bundled buildtools did not come from my end but from the maintainers of chromium-dev, and it looks like they at least had some reasons for their approach.

One reason might be simple:

[gerd@gerd-desktop bin]$ clang --version
clang version 11.1.0
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
[gerd@gerd-desktop bin]$ ./clang --version
clang version 13.0.0 (https://github.com/llvm/llvm-project/ a749bd76394c05b423cd643633188eb09f59fbe8)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/gerd/Downloads/chromium-dev/src/chromium-92.0.4498.0/third_party/llvm-build/Release+Asserts/bin/.

Looks like to compile Chromium (developer versions!) you will have to update clang first. As that is not trivial, the chromium-dev package maintainers tried to avoid it.

Last edited by DAC324 (2021-05-11 07:53:57)

Offline

#12 2021-05-11 11:10:03

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,867

Re: Makepkg: Run prepare() without extracting sources

clang version 13.0.0 (https://github.com/llvm/llvm-project/ a749bd76394c05b423cd643633188eb09f59fbe8)

Updating llvm/clang won't be enough.
Last stable release of llvm/clang is 12 , 13 is trunk .
That specific commit was added 27 days ago, so it does look like google uses a snapshot for chromium-dev .

Maybe those aur maintainers could separate building a snapshot of llvm/clang trunk to another package ?

Aur llvm-git & llvm-minimal-git as well as the pkgbuilds in Lordheavy's mesa-git repo could serve as examples how to build llvm/clang trunk versions .

https://aur.archlinux.org/packages/llvm-git/
https://aur.archlinux.org/packages/llvm-minimal-git/
https://gitlab.com/lordheavy/mesa-git/- … r/llvm-git


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Online

#13 2021-06-28 07:36:47

DAC324
Member
Registered: 2020-03-12
Posts: 80

Re: Makepkg: Run prepare() without extracting sources

eschwartz wrote:

So, this is:

  • not using the system clang (why not???)

That's why:

In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/memory:66:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_uninitialized.h:138:7: error: static_assert failed due to requirement 'is_constructible<(anonymous namespace)::PendingMessage, const (anonymous namespace)::PendingMessage &>::value' "result type must be constructible from value type of input range"
      static_assert(is_constructible<_ValueType2, decltype(*__first)>::value,
      ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_uninitialized.h:333:19: note: in instantiation of function template specialization 'std::uninitialized_copy<std::_Deque_iterator<(anonymous namespace)::PendingMessage, const (anonymous namespace)::PendingMessage &, const (anonymous namespace)::PendingMessage *>, std::_Deque_iterator<(anonymous namespace)::PendingMessage, (anonymous namespace)::PendingMessage &, (anonymous namespace)::PendingMessage *>>' requested here
    { return std::uninitialized_copy(__first, __last, __result); }
                  ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_deque.h:898:14: note: in instantiation of function template specialization 'std::__uninitialized_copy_a<std::_Deque_iterator<(anonymous namespace)::PendingMessage, const (anonymous namespace)::PendingMessage &, const (anonymous namespace)::PendingMessage *>, std::_Deque_iterator<(anonymous namespace)::PendingMessage, (anonymous namespace)::PendingMessage &, (anonymous namespace)::PendingMessage *>, (anonymous namespace)::PendingMessage>' requested here
      { std::__uninitialized_copy_a(__x.begin(), __x.end(),
             ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_queue.h:96:11: note: in instantiation of member function 'std::deque<(anonymous namespace)::PendingMessage>::deque' requested here
    class queue
          ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_uninitialized.h:92:8: note: in instantiation of function template specialization 'std::_Construct<std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>, const std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>> &>' requested here
                std::_Construct(std::__addressof(*__cur), *__first);
                     ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_uninitialized.h:151:2: note: in instantiation of function template specialization 'std::__uninitialized_copy<false>::__uninit_copy<const std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>> *, std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>> *>' requested here
        __uninit_copy(__first, __last, __result);
        ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_uninitialized.h:333:19: note: (skipping 3 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
    { return std::uninitialized_copy(__first, __last, __result); }
                  ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/vector.tcc:387:4: note: in instantiation of function template specialization 'std::vector<std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>>::_M_realloc_insert<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>' requested here
          _M_realloc_insert(begin() + __n, std::forward<_Args>(__args)...);
          ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_vector.h:1249:11: note: in instantiation of function template specialization 'std::vector<std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>>::_M_emplace_aux<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>' requested here
        { return _M_emplace_aux(__position, std::forward<_Args>(__args)...); }
                 ^
../../base/containers/flat_tree.h:1036:16: note: in instantiation of function template specialization 'std::vector<std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>>::emplace<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>' requested here
  return body_.emplace(position, std::forward<Args>(args)...);
               ^
../../base/containers/flat_map.h:293:19: note: in instantiation of function template specialization 'base::internal::flat_tree<std::pair<GURL, long>, base::internal::GetFirst, std::less<>, std::vector<std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>>>::unsafe_emplace<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>' requested here
    found = tree::unsafe_emplace(found, std::move(key), mapped_type());
                  ^
../../chrome/browser/push_messaging/push_messaging_service_impl.cc:451:32: note: in instantiation of member function 'base::flat_map<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>::operator[]' requested here
        message_delivery_queue_[{origin, service_worker_registration_id}];
                               ^
In file included from ../../chrome/browser/push_messaging/push_messaging_service_impl.cc:5:
In file included from ../../chrome/browser/push_messaging/push_messaging_service_impl.h:11:
In file included from ../../base/callback.h:14:
In file included from ../../base/bind.h:12:
In file included from ../../base/bind_internal.h:17:
In file included from ../../base/callback_internal.h:13:
In file included from ../../base/memory/ref_counted.h:14:
In file included from ../../base/check_op.h:12:
In file included from ../../base/template_util.h:10:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/iterator:66:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/streambuf_iterator.h:35:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/streambuf:41:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/ios_base.h:41:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/locale_classes.h:40:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/string:55:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/basic_string.h:40:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/ext/alloc_traits.h:34:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/alloc_traits.h:33:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_construct.h:109:38: error: call to implicitly-deleted copy constructor of '(anonymous namespace)::PendingMessage'
    { ::new(static_cast<void*>(__p)) _Tp(std::forward<_Args>(__args)...); }
                                     ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_uninitialized.h:92:8: note: in instantiation of function template specialization 'std::_Construct<(anonymous namespace)::PendingMessage, const (anonymous namespace)::PendingMessage &>' requested here
                std::_Construct(std::__addressof(*__cur), *__first);
                     ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_uninitialized.h:151:2: note: in instantiation of function template specialization 'std::__uninitialized_copy<false>::__uninit_copy<std::_Deque_iterator<(anonymous namespace)::PendingMessage, const (anonymous namespace)::PendingMessage &, const (anonymous namespace)::PendingMessage *>, std::_Deque_iterator<(anonymous namespace)::PendingMessage, (anonymous namespace)::PendingMessage &, (anonymous namespace)::PendingMessage *>>' requested here
        __uninit_copy(__first, __last, __result);
        ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_uninitialized.h:333:19: note: in instantiation of function template specialization 'std::uninitialized_copy<std::_Deque_iterator<(anonymous namespace)::PendingMessage, const (anonymous namespace)::PendingMessage &, const (anonymous namespace)::PendingMessage *>, std::_Deque_iterator<(anonymous namespace)::PendingMessage, (anonymous namespace)::PendingMessage &, (anonymous namespace)::PendingMessage *>>' requested here
    { return std::uninitialized_copy(__first, __last, __result); }
                  ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_deque.h:898:14: note: in instantiation of function template specialization 'std::__uninitialized_copy_a<std::_Deque_iterator<(anonymous namespace)::PendingMessage, const (anonymous namespace)::PendingMessage &, const (anonymous namespace)::PendingMessage *>, std::_Deque_iterator<(anonymous namespace)::PendingMessage, (anonymous namespace)::PendingMessage &, (anonymous namespace)::PendingMessage *>, (anonymous namespace)::PendingMessage>' requested here
      { std::__uninitialized_copy_a(__x.begin(), __x.end(),
             ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_queue.h:96:11: note: in instantiation of member function 'std::deque<(anonymous namespace)::PendingMessage>::deque' requested here
    class queue
          ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_uninitialized.h:92:8: note: (skipping 5 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
                std::_Construct(std::__addressof(*__cur), *__first);
                     ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/vector.tcc:387:4: note: in instantiation of function template specialization 'std::vector<std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>>::_M_realloc_insert<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>' requested here
          _M_realloc_insert(begin() + __n, std::forward<_Args>(__args)...);
          ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_vector.h:1249:11: note: in instantiation of function template specialization 'std::vector<std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>>::_M_emplace_aux<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>' requested here
        { return _M_emplace_aux(__position, std::forward<_Args>(__args)...); }
                 ^
../../base/containers/flat_tree.h:1036:16: note: in instantiation of function template specialization 'std::vector<std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>>::emplace<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>' requested here
  return body_.emplace(position, std::forward<Args>(args)...);
               ^
../../base/containers/flat_map.h:293:19: note: in instantiation of function template specialization 'base::internal::flat_tree<std::pair<GURL, long>, base::internal::GetFirst, std::less<>, std::vector<std::pair<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>>>::unsafe_emplace<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>' requested here
    found = tree::unsafe_emplace(found, std::move(key), mapped_type());
                  ^
../../chrome/browser/push_messaging/push_messaging_service_impl.cc:451:32: note: in instantiation of member function 'base::flat_map<std::pair<GURL, long>, std::queue<(anonymous namespace)::PendingMessage>>::operator[]' requested here
        message_delivery_queue_[{origin, service_worker_registration_id}];
                               ^
../../chrome/browser/push_messaging/push_messaging_service_impl.h:68:3: note: copy constructor is implicitly deleted because 'PendingMessage' has a user-declared move constructor
  PendingMessage(PendingMessage&& other);
  ^
2 errors generated.

The Chromium developers have decided to always use the latest GCC / clang trunk versions, instead of stable ones.

Offline

#14 2021-06-29 07:18:59

DAC324
Member
Registered: 2020-03-12
Posts: 80

Re: Makepkg: Run prepare() without extracting sources

Lone_Wolf wrote:
clang version 13.0.0 (https://github.com/llvm/llvm-project/ a749bd76394c05b423cd643633188eb09f59fbe8)

Maybe those aur maintainers could separate building a snapshot of llvm/clang trunk to another package ?

Perhaps people are hesitant to do that because installing clang in trunk version might break compiling for all other packages.
As I have learnt that programmers are carefully tailoring their code to the exact compiler version they use, it appears possible that after installing this trunk package, you will not be able to compile anything else that was written for clang 11 or lower versions.

Offline

#15 2021-06-29 10:07:05

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,867

Re: Makepkg: Run prepare() without extracting sources

That is easily solved by using a clean chroot[1] so only specific dependencies needed to build are present.

There are many posters on our forums with good packaging skills that can help creating a llvm/clang snapshot package.
(some even have actual experience maintaining llvm/clang packages )

Personally I try to stay away as far as possible from anything related to google, so am not interested in maintaining a llvm snapshot package for chromium.
If someone started such a package and posted about it, I am willing to help .


[1] https://wiki.archlinux.org/title/Develo … ean_chroot


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Online

#16 2021-08-14 10:37:22

DAC324
Member
Registered: 2020-03-12
Posts: 80

Re: Makepkg: Run prepare() without extracting sources

Sorry for now being entirely offtopic:

There is a repository of the latest Chromium development sources at AppSpot.

I am just wondering if these sources are created automatically, without any check if it is at all possible to compile them?

Reason for asking: Very often, they contain trivial errors such as missing includes that normally should have been detected when trying to compile them.

Does anybody know more?

Also, I found bugs.chromium.org but it is pretty quiet there. Is there a more appropriate place to get information about bugs and issues during chromium development?

Last edited by DAC324 (2021-08-14 10:40:28)

Offline

Board footer

Powered by FluxBB