On Fri, Jul 30, 2010 at 5:59 PM, David Cole david.c...@kitware.com wrote:
Here are the facts, as I see them:
- It would be possible to add automatic opt-in (not enabled by default)
library name decoration rules to CMake
- If the CMake team were to implement such a feature:
-- it would save
On 10. Aug, 2010, at 15:15 , Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 5:59 PM, David Cole david.c...@kitware.com wrote:
Here are the facts, as I see them:
- It would be possible to add automatic opt-in (not enabled by default)
library name decoration rules to CMake
- If the CMake
On 30. Jul, 2010, at 7:53 , Verweij, Arjen wrote:
Olaf,
Why?
I'm still waiting for someone to post a reason of why a decorated
name is a problem for them.
Also waiting on an answer to the code duplication issue.
Perhaps you should write a proposal that takes care of details, like how
On Fri, Jul 30, 2010 at 7:53 AM, Verweij, Arjen verwe...@tass-safe.com wrote:
Perhaps you should write a proposal that takes care of details, like how you
would like to see this decorated.
Good idea, as not everyone seems to understand my goals.
Then write a patch or create a cmake module
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild them...@gmail.com wrote:
First of all: There is almost NO duplication, since almost every project that
does decoration uses different conventions.
Duplication does not mean that the code is 100% equal.
Second: It is impossible for CMake do come
On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild them...@gmail.com wrote:
First of all: There is almost NO duplication, since almost every project
that does decoration uses different conventions.
Duplication does not mean that the code is
On 7/30/10 6:16 AM, Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wildthem...@gmail.com wrote:
First of all: There is almost NO duplication, since almost every project that
does decoration uses different conventions.
Duplication does not mean that the code is 100% equal.
On 7/30/10 6:45 AM, Michael Wild wrote:
On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wildthem...@gmail.com wrote:
First of all: There is almost NO duplication, since almost every project that
does decoration uses different conventions.
On Fri, Jul 30, 2010 at 1:45 PM, Michael Wild them...@gmail.com wrote:
On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild them...@gmail.com wrote:
First of all: There is almost NO duplication, since almost every project
that does decoration
On Fri, Jul 30, 2010 at 1:45 PM, Ryan Pavlik rpav...@iastate.edu wrote:
If you want to avoid code duplication, write a cmake module that does it
then share it with the world. This doesn't have to be a top-down solution:
if you think you have the best library decoration system wrapped in a
On Fri, Jul 30, 2010 at 1:49 PM, Ryan Pavlik rpav...@iastate.edu wrote:
And, if you ask any auto*-using developer how they feel about detecting and
configuring boost, prepare for some impolite words. Even the cmake module
for detecting it is complex.
(and auto-linking appears to only work on
On 7/30/10 6:58 AM, Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 1:49 PM, Ryan Pavlikrpav...@iastate.edu wrote:
And, if you ask any auto*-using developer how they feel about detecting and
configuring boost, prepare for some impolite words. Even the cmake module
for detecting it is
On Fri, Jul 30, 2010 at 2:05 PM, Ryan Pavlik rpav...@iastate.edu wrote:
It's a shame gcc doesn't support it yet. I would love to see support
there.
Olaf
The issue conceptually for me here, is that the code shouldn't/doesn't
necessarily know what exact library name to link against - think
On 7/30/10 7:11 AM, Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 2:05 PM, Ryan Pavlikrpav...@iastate.edu wrote:
It's a shame gcc doesn't support it yet. I would love to see support
there.
Olaf
The issue conceptually for me here, is that the code shouldn't/doesn't
necessarily know what
Please do explain. How would this work? What would the API be? And now it
suddenly sounds like CMake isn't supposed to do everything automagically
anymore. If that is the case, please RTFM and look into the OUTPUT_NAME
target property. It offers exactly what you want!
Or the prefix
On Fri, Jul 30, 2010 at 2:15 PM, Ryan Pavlik rpav...@iastate.edu wrote:
The issue conceptually for me here, is that the code shouldn't/doesn't
necessarily know what exact library name to link against - think
different
versions of libraries, different platforms...
Could you give a concrete
On 30. Jul, 2010, at 13:54 , Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 1:45 PM, Michael Wild them...@gmail.com wrote:
On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild them...@gmail.com wrote:
First of all: There is almost NO
On 30. Jul, 2010, at 14:16 , John Drescher wrote:
Please do explain. How would this work? What would the API be? And now it
suddenly sounds like CMake isn't supposed to do everything automagically
anymore. If that is the case, please RTFM and look into the OUTPUT_NAME
target property. It
On 30. Jul, 2010, at 14:31 , Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 2:25 PM, Michael Wild them...@gmail.com wrote:
Create a module and share it among your projects, possibly with others. If
it's any good it might get included in CMake.
I probably will.
On Windows, at least
On Fri, Jul 30, 2010 at 2:42 PM, Michael Wild them...@gmail.com wrote:
Oh, it IS library specific. Where do you think all these BOOST_MSVC and what
not come from? It is very specific to Boost. No other project will be able to
use this without heavy reworking.
That's just the MSVC version,
-
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Jul 30, 2010, at 8:46, Olaf van der Spek olafvds...@gmail.com wrote:
On Fri, Jul 30, 2010 at 2:42 PM, Michael Wild
On Fri, Jul 30, 2010 at 7:49 AM, Ryan Pavlik rpav...@iastate.edu wrote:
On 7/30/10 6:45 AM, Michael Wild wrote:
On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wildthem...@gmail.com wrote:
First of all: There is almost NO duplication, since
On 30. Jul, 2010, at 14:46 , Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 2:42 PM, Michael Wild them...@gmail.com wrote:
Oh, it IS library specific. Where do you think all these BOOST_MSVC and what
not come from? It is very specific to Boost. No other project will be able
to use this
On Fri, Jul 30, 2010 at 2:58 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
And what if someone else is using a different naming decoration for
their project than what is in the auto-link headers? Then you have to
update all those headers to your own naming scheme which amounts to a
Let's keep things calm, reasonable, rational here on the CMake mailing list.
It's a discussion. Some discussions require more patience than others... :-)
Olaf, clearly you have an idea that you are passionate about.
Just as clearly, most of the other responders to this topic have reasons to
be
Well let's look at how some things are handled.
direct X has multiple version of the same library, and msvcrt
(msvcrtd)... these are name mangled things.
.NET has moved to keeping seperate directories where everything is
exactly the same name.
Surely there's more than one paradigm that can be
Olaf,
Why?
I'm still waiting for someone to post a reason of why a decorated
name is a problem for them.
Also waiting on an answer to the code duplication issue.
Perhaps you should write a proposal that takes care of details, like how you
would like to see this decorated. Then write a patch
27 matches
Mail list logo
