westonpace commented on code in PR #14485:
URL: https://github.com/apache/arrow/pull/14485#discussion_r1003512612


##########
cpp/cmake_modules/ThirdpartyToolchain.cmake:
##########
@@ -1708,6 +1715,10 @@ macro(build_substrait)
   # Note: not all protos in Substrait actually matter to plan
   # consumption. No need to build the ones we don't need.
   set(SUBSTRAIT_PROTOS algebra extensions/extensions plan type)
+  set(ARROW_SUBSTRAIT_PROTOS extension_rels)
+  set(ARROW_SUBSTRAIT_PROTOS_DIR "${CMAKE_SOURCE_DIR}/proto")
+  message("SOURCE DIR IS ${SOURCE_DIR} AND ${CMAKE_SOURCE_DIR} AND 
${ARROW_SUBSTRAIT_PROTOS_DIR}"
+  )

Review Comment:
   ```suggestion
   ```
   This was just a debugging message



##########
cpp/src/arrow/engine/substrait/util.cc:
##########
@@ -125,7 +125,7 @@ Result<std::shared_ptr<RecordBatchReader>> 
ExecuteSerializedPlan(
     const ConversionOptions& conversion_options) {
   compute::ExecContext exec_context(arrow::default_memory_pool(),
                                     ::arrow::internal::GetCpuThreadPool(), 
func_registry);
-  ARROW_ASSIGN_OR_RAISE(auto plan, compute::ExecPlan::Make(&exec_context));
+  ARROW_ASSIGN_OR_RAISE(auto plan, compute::ExecPlan::Make());

Review Comment:
   We should revert this change.



##########
cpp/src/arrow/compute/exec/asof_join_benchmark.cc:
##########
@@ -76,7 +75,7 @@ static void TableJoinOverhead(benchmark::State& state,
   for (auto _ : state) {
     state.PauseTiming();
     ASSERT_OK_AND_ASSIGN(std::shared_ptr<arrow::compute::ExecPlan> plan,
-                         ExecPlan::Make(&ctx));
+                         ExecPlan::Make());

Review Comment:
   I think these are leftover from your brief merge on top of the PR that adds 
the proper single-threaded execution mode.  In that PR `ExecPlan::Make` no 
longer takes an exec context since the exec context has a thread pool and we 
don't want to actually provide or start using the thread pool until we start 
producing.  It's somewhat harmless here since `ctx` is identical to the default 
exec context.  However, it is not harmless in `substrait/util.cc` because the 
context there is actually using the CPU thread pool.



##########
cpp/src/arrow/engine/substrait/test_plan_builder.cc:
##########
@@ -88,16 +91,18 @@ Result<std::unique_ptr<substrait::ProjectRel>> 
CreateProject(
       // If it doesn't have a type then it's an enum
       const std::string& enum_value = arguments[arg_index];
       auto enum_ = std::make_unique<substrait::FunctionArgument::Enum>();
-      if (enum_value.size() > 0) {
-        enum_->set_specified(enum_value);
-      } else {
-        auto unspecified = std::make_unique<google::protobuf::Empty>();
-        enum_->set_allocated_unspecified(unspecified.release());
-      }
+      enum_->set_specified(enum_value);

Review Comment:
   It's part of adapting to the new options format.  Function arguments can no 
longer be unspecified.



##########
cpp/cmake_modules/ThirdpartyToolchain.cmake:
##########
@@ -1758,6 +1769,29 @@ macro(build_substrait)
 
     list(APPEND SUBSTRAIT_SOURCES "${SUBSTRAIT_PROTO_GEN}.cc")
   endforeach()
+  message("SOURCE DIR2 IS ${SOURCE_DIR} AND ${CMAKE_SOURCE_DIR} AND 
${ARROW_SUBSTRAIT_PROTOS_DIR}"
+  )

Review Comment:
   ```suggestion
   ```



##########
cpp/proto/substrait/extension_rels.proto:
##########
@@ -0,0 +1,44 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+syntax = "proto3";
+
+package arrow.substrait;

Review Comment:
   I'm not a big fan of needing all of the:
   ```
   namespace substrait = ::substrait;
   ```
   
   but I suppose we can live with it if you are determined to have this package 
name.  Did `package arrow.substrait_ext` not work?
   
   Could there be another alternative?  Would it be tolerable to have `package 
substrait.arrow` instead?  It's somewhat unfortunate that protobuf doesn't have 
options for controlling the C++ namespace like they do for Java & C#.



##########
cpp/cmake_modules/ThirdpartyToolchain.cmake:
##########
@@ -657,6 +657,13 @@ else()
            
"${THIRDPARTY_MIRROR_URL}/snappy-${ARROW_SNAPPY_BUILD_VERSION}.tar.gz")
 endif()
 
+# Remove these two lines once 
https://github.com/substrait-io/substrait/pull/342 merges
+set(ENV{ARROW_SUBSTRAIT_URL}
+    
"https://github.com/substrait-io/substrait/archive/e59008b6b202f8af06c2266991161b1e45cb056a.tar.gz";
+)
+set(ARROW_SUBSTRAIT_BUILD_SHA256_CHECKSUM
+    "f64629cb377fcc62c9d3e8fe69fa6a4cf326f34d756e03db84843c5cce8d04cd")

Review Comment:
   Hmm...this isn't great to be relying on a Substrait fork.  That being said, 
we aren't going to be compatible with anything until 
https://github.com/substrait-io/substrait/pull/342 merges.  So I suppose this 
is just a natural consequence of working with emerging specifications.  It puts 
us in a better state for the short term.



##########
cpp/src/arrow/engine/substrait/plan_internal.cc:
##########
@@ -132,10 +135,29 @@ Result<ExtensionSet> GetExtensionSetFromPlan(const 
substrait::Plan& plan,
                             conversion_options, registry);
 }
 
+namespace {
+
+// FIXME Is there some way to get these from the cmake files?

Review Comment:
   ```suggestion
   // TODO(ARROW-18145) Populate these from cmake files
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to