Goost not building from source with default installation instructions on Linux Ubuntu

[paulicka]

Goost and Godot version:

Default version from following installation instructions: git clone https://github.com/goostengine/goost --recurse-submodules

OS/platform/device including version:

Linux quasar 5.4.0-122-generic #138-Ubuntu SMP Wed Jun 22 15:00:31 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Linux Mint Cinnamon on HP Spectre

Issue description:

$ scons
...
/home/hanumanji/Documents/goost/core/types/graph.cpp:578:27:   required from here
/home/hanumanji/Documents/goost/core/types/templates/priority_queue.h:62:10: error: ambiguous overload for 'operator=' (operand types are 'LocalVector<GraphVertex*, int, false>' and 'const LocalVector<GraphVertex*, unsigned int, false>')
   62 |   vector = p_elements;
      |   ~~~~~~~^~~~~~~~~~~~
In file included from ./core/pooled_list.h:55,
                 from ./core/rid_handle.h:36,
                 from ./core/rid.h:36,
                 from ./core/ref_ptr.h:40,
                 from ./core/variant.h:49,
                 from ./core/method_ptrcall.h:36,
                 from ./core/method_bind.h:35,
                 from ./core/class_db.h:34,
                 from ./core/resource.h:34,
                 from /home/hanumanji/Documents/goost/core/types/graph.h:3,
                 from /home/hanumanji/Documents/goost/core/types/graph.cpp:1:
./core/local_vector.h:290:22: note: candidate: 'LocalVector<T, U, force_trivial>& LocalVector<T, U, force_trivial>::operator=(const Vector<T>&) [with T = GraphVertex*; U = int; bool force_trivial = false]'
  290 |  inline LocalVector &operator=(const Vector<T> &p_from) {
      |                      ^~~~~~~~
./core/local_vector.h:297:22: note: candidate: 'LocalVector<T, U, force_trivial>& LocalVector<T, U, force_trivial>::operator=(const PoolVector<T>&) [with T = GraphVertex*; U = int; bool force_trivial = false]'
  297 |  inline LocalVector &operator=(const PoolVector<T> &p_from) {
      |                      ^~~~~~~~
[Initial build] Compiling ==> /home/hanumanji/Documents/goost/scene/audio/register_audio_types.cpp
scons: *** [/home/hanumanji/Documents/goost/core/types/graph.x11.tools.64.goost.o] Error 1
scons: building terminated because of errors.
[Time elapsed: 00:00:10.652]

Steps to reproduce:

Follow default compile from source instructions:

 2109  git clone https://github.com/goostengine/goost --recurse-submodules
 2110  cd goost/
 2111  python goost.py config
 2112  scons

Is this issue reproducible in official Godot builds?

I can build from godot on master branch without problems, so it's not obviously my toolchain causing issues (I think?).

Minimal reproduction project:

Again, just the default instructions are failing me in my environment.

[Xrayez]

Perhaps this may be due to breaking core changes in Godot, again.

I no longer use Godot, bug fixes are welcomed.

[Meptl]

I'm able to compile with the following patch (on gd3 e5d9b18) and Godot 3.5-stable (991bb6ac74).

diff --git a/core/types/templates/priority_queue.h b/core/types/templates/priority_queue.h
index ecc779f..60a8db7 100644
--- a/core/types/templates/priority_queue.h
+++ b/core/types/templates/priority_queue.h
@@ -12,7 +12,7 @@ struct PriorityQueueMaxHeapComparator {

 template <typename T, class Comparator=PriorityQueueMinHeapComparator<T>>
 class PriorityQueue {
-   LocalVector<T, int> vector;
+   LocalVector<T> vector;

    _FORCE_INLINE_ int parent(int i) const {
        return (i - 1) / 2;

I'm not too versed in C++ and I'm not using the Graph structure (the only consumer of PriorityQueue AFAICT) for my project, so I can't say if this is a functional fix. But the units tests pass:

python run.py tests --test-file core/types/test_graph.gd

...

260 passed 0 failed.  Tests finished in 0.2s

[Xrayez]

@Meptl looks fine, feel free to submit a pull request. 🙂

[Meptl]

Filed https://github.com/goostengine/goost/pull/196

That PR builds with 3.x but not 3.5-stable. A bit larger than the patch I posted because our CICD compiles with werror=1 warnings=all

[Xrayez]

I assume this to be fixed via #196, thanks!