Hi Roger, Building in a separate build directory is not an option for me because I have to use my employer's makefile harness for deploying cmake-based third-party applications. I cannot alter this harness.
My colleagues and I have decided to forego the xalan-c tests and samples for the time being. We will include them when the 1.13 release becomes available. Regards, Paul From: Roger Leigh <rle...@codelibre.net> Sent: Sunday, July 26, 2020 3:35 PM To: dev@xalan.apache.org Subject: Re: Xalan 1.12 samples and tests fail to build on Linux and the Mac Hi Paul, All you have to do is make a temporary build directory and run cmake from there, for example: mkdir build cd build cmake <options> /path/to/xalan-c and it will then build. That /should/ work, because that's what the CI build does and that's working just fine: https://github.com/apache/xalan-c/blob/master/scripts/ci-travis#L25<https://github.com/apache/xalan-c/blob/master/scripts/ci-travis#L25> If you can get that working, hopefully it will be a workaround until this is fixed in the next release. Kind regards, Roger On 26/07/2020 15:01, Paul Kinnucan wrote: Hi Roger, Thanks for the suggestions. I tried unsuccessfully to get cmake to use a different build directory. I am new to cmake so I was guessing what I needed to do and my many guesses were wrong. I am going to try moving the sample and example source directories into src directories below the top directories. This seems to me to require the fewest changes to the cmake build and test scripts for the samples and tests. All I have to do is change the location of the sources in the add_executable commands. The rest of the script should work as is to build and test the executables in the top directories. I'll let you know how I fare. Regards, Paul From: Roger Leigh <rle...@codelibre.net><mailto:rle...@codelibre.net> Sent: Saturday, July 25, 2020 4:32 PM To: dev@xalan.apache.org<mailto:dev@xalan.apache.org> Subject: Re: Xalan 1.12 samples and tests fail to build on Linux and the Mac Hi Paul, A quick workaround to try: use a separate build directory then you'll avoid the naming conflicts. We will absolutely need to fix this. I copied the existing convention but I agree that adopting the Xerces-C++ strategy will be a better solution. See https://issues.apache.org/jira/browse/XALANC-811<https://issues.apache.org/jira/browse/XALANC-811> which I created to track this. An alternative approach would be to deliberately forbid in-source builds and require a separate build directory. Kind regards, Roger On 24/07/2020 22:53, Paul Kinnucan wrote: Hi, The Xalan 1.12 samples and tests fail to build on Linux and the Mac. The reason is that the cmake build infrastructure tries to output the sample and test binaries at the top level of the samples and Tests directories, respectively. For example, the samples directory has the following structure: samples ApacheModduleXSLT CompileStylesheet DocumentBuilder EntityResolver ExternalFunction ... The Xalan build infrastructure tries to create the sample executable in the root of the samples directory. This leads to a naming conflict. For example, the build intrastructure tells the linker to output the ExternalFunction executable at the root of the samples directory. The linker open function fails with the error message [ 93%] Building CXX object src/xalanc/TestXPath/CMakeFiles/TestXPath.dir/TestXPath.cpp.o cd /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath && /mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/g++ -DNDEBUG -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/PlatformSupport -isystem /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/icu/include -isystem /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/xerces-c/include -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/NLS/include -O2 -pipe -pthread -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox= -fPIC -std=c++11 -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 -Wmissing-declarations -Wno-long-long -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros -fstrict-aliasing -O2 -pipe -pthread -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox= -fPIC -std=c++11 -std=gnu++14 -o CMakeFiles/TestXPath.dir/TestXPath.cpp.o -c /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath/TestXPath.cpp /mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: fatal error: ExternalFunction: open: Is a directory I noticed that Xerces-c stores the source for its tests and samples in a src subdirectory but creates the executables at the top of the directory e.g., samples src CreateDOMDocument CreateDOMDocument This avoids the naming conflict. The Xalan-c samples and tests build without issue on Windows. Thanks for creating a version of Xalan-c that is easy to build on all major platforms. Regards, Paul Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
