Alan W. Irwin wrote:
On 2008-03-23 16:58-0400 Miguel A. Figueroa-Villanueva wrote:
On Sun, Mar 23, 2008 at 3:46 PM, Alan W. Irwin wrote:
The difference is caused because FindwxWidgets delivers
wxWidgets_DEFINITIONS as a blank delimited string for 2.4.8 and as a
list
for the cvs version.
Hello Alan,
Sorry for the confusion. This change was made as a bug fix to resolve
a problem reported to the list. Can't remember the error that was
generated, but it was possibly to handle spaces in definitions (i.e.,
-DFOO="A space containing string") or some of the other variables. You
can see the patch applied at:
http://www.cmake.org/cgi-bin/viewcvs.cgi/Modules/FindwxWidgets.cmake?root=CMake&r1=1.7&r2=1.8
Yes, it appears to be a classic case of it being impossible to address one
important issue without creating a backwards incompatibility.
The problem is that it seems you are using (abusing?) the use of the
interface variables. That is, you are not using ADD_DEFINITIONS and
INCLUDE_DIRECTORIES, but building the compile flags directly?
Yes. The problem with INCLUDE_DIRECTORIES (and ADD_DEFINITIONS?) is they
apply to everything built in that directory. I far prefer to use explicit
compile flags for each shared object I am building in that directory.
[out of order for clarity] In sum, Bill, I hope you consider making
separate module releases to
absolutely insure backwards module compatibility for those who stick
with a
particular module release while being allowed to change cmake
version. This
would also have the simultanous benefit of freeing the module
developers to
get on with improving the modules without enforcing strict backwards
compatibility.
Although I understand what you are pointing out, I'm not sure that
this is good in the sense that there is a maintainence overhead added.
It would be some extra work to set this up for the first time, but if
automated properly, I don't think there would be a lot of on-going work
once
this was set up.
[...]That said, I do believe the find modules should have a process to
deprecate variables and evolve... I'm just not sure if we want an
independent release schedule.
Just my $.02...
I agree with the general goal of allowing the modules to evolve in a
reasonable way (such as the change you made) so long as we provide some
mechanism to assure backwards compatibility. My understanding of how Bill
currently handles this issue is he is ultra-cautious about making any
changes to modules _that are released_. In practice this may mean your
greatly improved FindwxWidgets.cmake in cvs will not get into the next
release because of the above demonstrated backwards incompatibility. That
would be a real shame, and I would like to find some other method of
freezing the modules such as providing easy access to previous module
releases. I don't care about the details so long as something is done
about
this issue other than the current virtual freeze on module changes that are
allowed to get into releases.
I don't like to put major changes in modules into patch releases. We are
now working on a major release 2.6, so I am putting in all module
changes. I don't see how having a separate release track for modules
would help things. It would require two separate downloads for CMake?
The number one objection to adopting CMake is having to install CMake
before being able to build a project. I don't want to make that
download any more complicated. If someone wants a fix in a module, it
is very easy to copy the module into the project and override the one in
CMake.
I will have to look into this space vs. ; separation issue. I do think
plplot is abusing things a bit, and should not be constructing -I stuff,
as it may not be portable to IDE's and other compilers in the future.
Some compiler may not even know what -I is. CMake is supposed to hide
low level things like that from the user. I am aware of the issue with
target vs. directory level includes and defines, and at some point it
will get fixed with a target property. For now, I would recommend that
projects use the directory level includes and defines if at all possible
as it will be much more portable.
I am thinking that maybe I can add some checks into the wx stuff to look
for spaces in the define list, and only then separate with ;. This can
not break any project because it will still be space separated unless
there is something with a space. The something with a space would have
been broken anyway, and no project could have depended on it working
that way.
-Bill
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
