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
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>
*Sent:* Saturday, July 25, 2020 4:32 PM
*To:* 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
