Cannot run clang regression tests with cmake

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Cannot run clang regression tests with cmake

İsmail Dönmez
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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

arrowdodger
On Thu, May 19, 2011 at 7:45 PM, İsmail Dönmez <[hidden email]> wrote:
And nothing happens, in an autoconf build it would run the clang regression tests. Am I missing something?

Do make clang-test in build/ dir.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

İsmail Dönmez
Hi;

On Thu, May 19, 2011 at 5:50 PM, arrowdodger <[hidden email]> wrote:
On Thu, May 19, 2011 at 7:45 PM, İsmail Dönmez <[hidden email]> wrote:
And nothing happens, in an autoconf build it would run the clang regression tests. Am I missing something?

Do make clang-test in build/ dir.

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?

Regards,
ismail


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

Óscar Fuentes
İsmail Dönmez <[hidden email]> 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.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

arrowdodger
On Thu, May 19, 2011 at 8:28 PM, Óscar Fuentes <[hidden email]> wrote:
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?

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

İsmail Dönmez
In reply to this post by Óscar Fuentes
Hi;

On Thu, May 19, 2011 at 6:28 PM, Óscar Fuentes <[hidden email]> wrote:
İsmail Dönmez <[hidden email]> 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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

Óscar Fuentes
In reply to this post by arrowdodger
arrowdodger <[hidden email]> writes:

> On Thu, May 19, 2011 at 8:28 PM, Óscar Fuentes <[hidden email]> wrote:
>
>> 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.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

İsmail Dönmez
Hi;

On Thu, May 19, 2011 at 7:30 PM, Óscar Fuentes <[hidden email]> wrote:
arrowdodger <[hidden email]> writes:

> On Thu, May 19, 2011 at 8:28 PM, Óscar Fuentes <[hidden email]> wrote:
>
>> 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.

Windows developers are already aware of this problem and can deal with it. The rest of the world including OSX, *BSD, Linux uses libfoo.ext naming. So you are sacrificing all of these for the sake of Windows.

Regards,
ismail
 

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

Douglas Gregor
In reply to this post by Óscar Fuentes

On May 19, 2011, at 10:30 AM, Óscar Fuentes wrote:

> arrowdodger <[hidden email]> writes:
>
>> On Thu, May 19, 2011 at 8:28 PM, Óscar Fuentes <[hidden email]> wrote:
>>
>>> 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.

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

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

Óscar Fuentes
Douglas Gregor <[hidden email]> 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.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

İsmail Dönmez
Hi;

On Thu, May 19, 2011 at 8:55 PM, Óscar Fuentes <[hidden email]> wrote:
Douglas Gregor <[hidden email]> 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.

If you say cmake is for Windows users only its OK, otherwise default should be in compliant with most of the platforms.

Regards,
ismail
 

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

Óscar Fuentes
İsmail Dönmez <[hidden email]> 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)

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

İsmail Dönmez


2011/5/19 Óscar Fuentes <[hidden email]>
İsmail Dönmez <[hidden email]> 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 ;)
 
> 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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

Dean Pavlekovic
In reply to this post by Óscar Fuentes
Hi,

On Thu, May 19, 2011 at 7:30 PM, Óscar Fuentes <[hidden email]> wrote:
arrowdodger <[hidden email]> writes:

> On Thu, May 19, 2011 at 8:28 PM, Óscar Fuentes <[hidden email]> wrote:
>
>> 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


 
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.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot run clang regression tests with cmake

Manuel Klimek
In reply to this post by Óscar Fuentes
On Thu, May 19, 2011 at 10:30 AM, Óscar Fuentes <[hidden email]> wrote:

> arrowdodger <[hidden email]> writes:
>
>> On Thu, May 19, 2011 at 8:28 PM, Óscar Fuentes <[hidden email]> wrote:
>>
>>> 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

>
> 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.
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev