Cannot run clang regression tests with cmake

Hi;

Latest svn.

mkdir build
cd build
cmake …
make

cd tools/clang
make test

And nothing happens, in an autoconf build it would run the clang regression tests. Am I missing something?

Regards,
ismail

Do make clang-test in build/ dir.

Hi;

İsmail Dönmez <ismail@namtrac.org> writes:

Thanks, my one other big complaint with cmake is that it produces:

liblibclang.a
liblibclang.so.3.0

It might be OK on Windos but this is really wrong on Linux and other Unix
variants, shouldn't this be done only for Windows port if at all?

Then users maintaining cross-platform projects would need to
discriminate the library name by toolchain, which is not very
friendly. I'm supposing that most people use either cmake or
configure&make for their client projects, not both.

The name liblibclang is forced by an unfortunate collision between MS
and GNU name conventions. We can't create clang.dll with MS since we
already have clang.exe on the same directory (.pdb, .ilk and possibly
other files collide) so we must use some other name for clang.dll, like
libclang.dll. Then this produces liblibclang.so on GNU.

I’ve wanted to ask earleir, but forgot about it:
Why we can’t produce libclang.dll on Win and clang.so on Unixies?

I’ve wanted to ask earleir, but forgot about it:
Why we can’t produce libclang.dll on Win and clang.so on Unixies?

I meant “libclang.so on Unixies using simple if() else() construct in CMakeLists.txt?”

Hi;

İsmail Dönmez <ismail@namtrac.org> writes:

Thanks, my one other big complaint with cmake is that it produces:

liblibclang.a
liblibclang.so.3.0

It might be OK on Windos but this is really wrong on Linux and other Unix
variants, shouldn’t this be done only for Windows port if at all?

Then users maintaining cross-platform projects would need to
discriminate the library name by toolchain, which is not very
friendly. I’m supposing that most people use either cmake or
configure&make for their client projects, not both.

Well this rules out using cmake on Linux because liblibclang.so is wrong from shared lib perspective.

The name liblibclang is forced by an unfortunate collision between MS
and GNU name conventions. We can’t create clang.dll with MS since we
already have clang.exe on the same directory (.pdb, .ilk and possibly
other files collide) so we must use some other name for clang.dll, like
libclang.dll. Then this produces liblibclang.so on GNU.

Well there is no need to for this on !Windows platforms imho.

Regards,
ismail

arrowdodger <6yearold@gmail.com> writes:

The name liblibclang is forced by an unfortunate collision between MS
and GNU name conventions. We can't create clang.dll with MS since we
already have clang.exe on the same directory (.pdb, .ilk and possibly
other files collide) so we must use some other name for clang.dll, like
libclang.dll. Then this produces liblibclang.so on GNU.

I've wanted to ask earleir, but forgot about it:
Why we can't produce libclang.dll on Win and clang.so on Unixies?

For the resason explained on the text you didn't quote. The user would
need to be aware of the difference and do:

if( MSVC )
  target_link_libraries(myproject libclang)
else()
  target_link_libraries(myproject clang)
endif()

Of course this is not a reason that makes impossible to do what you
suggest. I picked a trade-off. If the consensus is that using different
names is the right thing, it's okay with me. However, I don't accept
reasonings of the type: "since I only work on Linux I don't care about
whatever problems Windows users may have." Please keep in mind that for
MSVC users cmake is the only way of building LLVM/Clang.

Hi;

Isn't this why CMake has the OUTPUT_NAME target property?

  - Doug

Douglas Gregor <dgregor@apple.com> writes:

I've wanted to ask earleir, but forgot about it:
Why we can't produce libclang.dll on Win and clang.so on Unixies?

For the resason explained on the text you didn't quote. The user would
need to be aware of the difference and do:

if( MSVC )
target_link_libraries(myproject libclang)
else()
target_link_libraries(myproject clang)
endif()

Of course this is not a reason that makes impossible to do what you
suggest. I picked a trade-off. If the consensus is that using different
names is the right thing, it's okay with me. However, I don't accept
reasonings of the type: "since I only work on Linux I don't care about
whatever problems Windows users may have." Please keep in mind that for
MSVC users cmake is the only way of building LLVM/Clang.

Isn't this why CMake has the OUTPUT_NAME target property?

This is not a technical problem. We know how to implement any of the
choices under consideration.

The discussion is about favoring the users who use cmake for
cross-platform development on Windows and Unix or the users who
simultaneously use the cmake build and the traditional one.

Hi;

İsmail Dönmez <ismail@namtrac.org> writes:

The discussion is about favoring the users who use cmake for
cross-platform development on Windows and Unix or the users who
simultaneously use the cmake build and the traditional one.

If you say cmake is for Windows users only

The LLVM cmake build spec is for Visual Studio users (their only choice)
and for anyone who prefers using cmake over the traditional system.

its OK, otherwise default should be in compliant with most of the
platforms.

Please give chapter and verse.

Note that the target name is "libclang" (That's splitting hairs, but I
can't see why creating a library with a file name such as liblibclang.so
is sinful)

2011/5/19 Óscar Fuentes <ofv@wanadoo.es>

İsmail Dönmez <ismail@namtrac.org> writes:

The discussion is about favoring the users who use cmake for
cross-platform development on Windows and Unix or the users who
simultaneously use the cmake build and the traditional one.

If you say cmake is for Windows users only

The LLVM cmake build spec is for Visual Studio users (their only choice)
and for anyone who prefers using cmake over the traditional system.

It would be nice if this “feature” is documented :wink:

its OK, otherwise default should be in compliant with most of the
platforms.

Please give chapter and verse.

Sins of Unixers 13:337

Note that the target name is “libclang” (That’s splitting hairs, but I
can’t see why creating a library with a file name such as liblibclang.so
is sinful)

Ah well, I’ll just patch the CMakeLists.txt.

Regards,
ismail

Hi,

arrowdodger <6yearold@gmail.com> writes:

The name liblibclang is forced by an unfortunate collision between MS
and GNU name conventions. We can’t create clang.dll with MS since we
already have clang.exe on the same directory (.pdb, .ilk and possibly
other files collide) so we must use some other name for clang.dll, like
libclang.dll. Then this produces liblibclang.so on GNU.

I’ve wanted to ask earleir, but forgot about it:
Why we can’t produce libclang.dll on Win and clang.so on Unixies?

For the resason explained on the text you didn’t quote. The user would
need to be aware of the difference and do:

if( MSVC )
target_link_libraries(myproject libclang)
else()
target_link_libraries(myproject clang)
endif()

FWIW, one could use something like:

if(MSVC)
set(CMAKE_SHARED_LIBRARY_PREFIX “lib”)
endif()

This apparently builds “libxyz.dll” with “xyz.lib” import library. .ilk & .pdb also have “lib” prefix in this case so there’s no potential clash with clang.exe.
User would then need to have only target_link_libraries(myproject clang) on all platforms. http://www.vtk.org/Wiki/CMake_Useful_Variables#Prefixes.2C_Suffixes_.28Postfixes.29.2C_and_Extensions (they say it’s read only var there, but apparently works)

Cheers,
Dean

arrowdodger <6yearold@gmail.com> writes:

The name liblibclang is forced by an unfortunate collision between MS
and GNU name conventions. We can't create clang.dll with MS since we
already have clang.exe on the same directory (.pdb, .ilk and possibly
other files collide) so we must use some other name for clang.dll, like
libclang.dll. Then this produces liblibclang.so on GNU.

I've wanted to ask earleir, but forgot about it:
Why we can't produce libclang.dll on Win and clang.so on Unixies?

For the resason explained on the text you didn't quote. The user would
need to be aware of the difference and do:

Which user are you referring to? I would imagine 2 types of users, one
being the internal calls from the clang/llvm tree, and the other one
being users using an installed libclang. The internal users already
have clang/llvm specific calls. For the users using the installed
libclang I would imagine a FindLibClang.cmake module that gives a
variable that is correctly set for the platform the user is currently
on.

Cheers,
/Manuel