[BUG]: #define print replaces print functions in other libraries

[Mike Mullen]

Describe the Bug
In source file /include/matx/core/tensor_utils.h on line 1176, the macro does not acknowledge the namespace it is nested in. Any code written or included after this file has been included has its print function replaced with MatX's version, even if the other library has a properly namespaced print method written (e.g. not as a macro). This makes the include order of headers affect the compilation of even trivial files, example below.

To Reproduce
Steps to reproduce the behavior:

1. Attempt to compile the code below, using the attached CMakeLists.txt (note: I pass in a non-system path with -DCMAKE_PREFIX_PATH for the location of MatX)
2. Compilation fails in Eigen, which has a Eigen::internal::print method, that is replaced by MatX's print.
3. Compilation and execution succeed if Eigen is included before MatX.

Expected Behavior
Compilation and execution success should be independent of header include order.

Code Snippets
matxTest.cu

#include <matx.h>
#include <Eigen/Core>
#include <iostream>

int main( int argc, char** argv )
{
    std::cout << "Pure CUDA" << std::endl;
}

System Details (please complete the following information):

• OS: Ubuntu 22.04
• CUDA version: 12.2.140
• g++ version: 11.4.0

Additional Context
Not a find or awk guru, but if you run find . -type f -exec awk '(/print/ && !/fprint/ && !/printf/ && !/_print_/){print FILENAME ":\t" $0;}' '{}' \; inside MatX/include/, there seem to be no uses of this print macro in the core library. It is used in examples, tests, and docs though it appears. I think renaming the macro to be matx specific, like matx_print would be sufficient to prevent conflicts with other libraries, and am happy to open a PR when a consensus is reached on how to best fix the issue.

[Mike Mullen]

I should add, I explicitly specified my CUDA arch in CMakeLists.txt, that will likely need to be changed for anyone trying to reproduce this.

[Tim Martin]

Thank you for the feedback! This is fixed by PR #607.

[Mike Mullen]

Nice thanks for the quick fix!