From perera@cs.rpi.edu Sun Jan 6 20:13:37 2002 From: perera@cs.rpi.edu (Amitha Perera) Date: Sun, 6 Jan 2002 15:13:37 -0500 Subject: [Cmake] Symbolic pathname translation Message-ID: <20020106151337.K11388@cs.rpi.edu> Hi all I've just committed a change that allows the pathnames generated by CMake to maintain symbolic links. If cmake is invoked with two paths--the first to the source directory, the second to the output directory--those paths will be used "as is" to refer to the roots of the source and output trees. I call this pathname translation, and is only enabled with this special two directory invocation. It shouldn't break cmake for anyone. If it does, please let me know and I'll try fix it. To illustrate further: suppose your source and output directories are /my/src and /my/bin, and on your machine (my.machine), these are symbolic links to a locally mounted disk: my.machine: /my/src links to /localdisk/src my.machine: /my/bin links to /localdisk/bin If you run CMake as normal cd /my/bin; cmake /my/src all the paths will refer to /localdisk/src and /localdisk/bin. Suppose these disks are network mounted on a different machine (other.machine) as other.machine: /my/src links to /nfs/my.machine/src other.machine: /my/bin links to /nfs/my.machine/bin Then, attempting to compile the source or to run dynamically linked executables on other.machine will fail because all references to /localdisk are invalid. If, my.machine, you run CMake with pathname translation cd /localdisk/bin; cmake /my/src /my/bin Then CMake will automatically replace all references to /localdisk/src with /my/src and to /localdisk/bin with /my/bin. Assuming /my/src and /my/bin are valid aliases network-wide, then all is well on other.machine. For pathname translation to be enabled, the symbolic source and output directories must be absolute paths, and the output directory must refer to the current directory. (I.e. cmake must be run from the output directory.) Amitha. From millerjv@crd.ge.com Mon Jan 7 18:42:55 2002 From: millerjv@crd.ge.com (Miller, James V (CRD)) Date: Mon, 7 Jan 2002 13:42:55 -0500 Subject: [Cmake] What "path" do custom commands use? Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C197AB.1F0270E0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C197AB.1F0270E0" ------_=_NextPart_001_01C197AB.1F0270E0 Content-Type: text/plain; charset="iso-8859-1" I am having a problem with the cmFLTKWrapUICommand when it is run on the PC. When fluid.exe is run, it cannot find a required dll. The specific dll is one that Intel C++ provides which is what I used to build fltk. I can run fluid from the command line and it works fine. However, when DevStudio runs fluid as a custom command, the search path does not include the directory that has the Intel C++ dlls. This directory is in my path when I run from the comand line. Do custom commands have a special "path" associated with them? Is this a DevStudio problem? Jim Miller _____________________________________ Visualization & Computer Vision GE Corporate Research & Development Bldg. KW, Room C218B P.O. Box 8, Schenectady NY 12301 millerjv@crd.ge.com < mailto:millerjv@crd.ge.com > (518) 387-4005, Dial Comm: 8*833-4005, Cell: (518) 505-7065, Fax: (518) 387-6981 ------_=_NextPart_001_01C197AB.1F0270E0 Content-Type: text/html; charset="iso-8859-1"

I am having a problem with the cmFLTKWrapUICommand when it is run on the PC. When fluid.exe is run, it cannot find a required dll. The specific dll is one that Intel C++ provides which is what I used to build fltk.

I can run fluid from the command line and it works fine. However, when DevStudio runs fluid as a custom command, the search path does not include the directory that has the Intel C++ dlls. This directory is in my path when I run from the comand line.

Do custom commands have a special "path" associated with them? Is this a DevStudio problem?

Jim Miller
_____________________________________
Visualization & Computer Vision
GE Corporate Research & Development
Bldg. KW, Room C218B
P.O. Box 8, Schenectady NY 12301

millerjv@crd.ge.com <mailto:millerjv@crd.ge.com>
(518) 387-4005, Dial Comm: 8*833-4005,
Cell: (518) 505-7065, Fax: (518) 387-6981

------_=_NextPart_001_01C197AB.1F0270E0-- ------_=_NextPart_000_01C197AB.1F0270E0 Content-Type: application/octet-stream; name="Miller, James V (CRD).vcf" Content-Disposition: attachment; filename="Miller, James V (CRD).vcf" BEGIN:VCARD VERSION:2.1 N:Miller;James FN:Miller, James V (CRD) ORG:CRD;ESL TITLE:Computer Scientist TEL;WORK;VOICE:*833-4005 TEL;WORK;VOICE:1 518 387-4005 ADR;WORK:;KW-C218B;P.O. Box 8;Schenectady;New York;12301;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:KW-C218B=0D=0AP.O. Box 8=0D=0ASchenectady, New York 12301=0D=0AUSA EMAIL;PREF;INTERNET:millerjv@crd.ge.com REV:20010420T140329Z END:VCARD ------_=_NextPart_000_01C197AB.1F0270E0-- From bill.hoffman@kitware.com Mon Jan 7 18:54:23 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Mon, 07 Jan 2002 13:54:23 -0500 Subject: [Cmake] What "path" do custom commands use? In-Reply-To: Message-ID: <5.0.2.1.0.20020107134850.03d2eea0@pop.nycap.rr.com> --=====================_857301003==_.ALT Content-Type: text/plain; charset="us-ascii" This is a "fun" problem with MSDev. MSDev has a nice feature of taking a snapshot of your PATH when it is installed. From that point on it ignores the system PATH. You can manually add new paths in Tools->Options->Directories->Executables. -Bill At 01:42 PM 1/7/2002 -0500, Miller, James V (CRD) wrote: >I am having a problem with the cmFLTKWrapUICommand when it is run on the PC. When fluid.exe is run, it cannot find a required dll. The specific dll is one that Intel C++ provides which is what I used to build fltk. > >I can run fluid from the command line and it works fine. However, when DevStudio runs fluid as a custom command, the search path does not include the directory that has the Intel C++ dlls. This directory is in my path when I run from the comand line. > >Do custom commands have a special "path" associated with them? Is this a DevStudio problem? > >Jim Miller >_____________________________________ >Visualization & Computer Vision >GE Corporate Research & Development >Bldg. KW, Room C218B >P.O. Box 8, Schenectady NY 12301 > >millerjv@crd.ge.com <mailto:millerjv@crd.ge.com> >(518) 387-4005, Dial Comm: 8*833-4005, >Cell: (518) 505-7065, Fax: (518) 387-6981 > > --=====================_857301003==_.ALT Content-Type: text/html; charset="us-ascii" This is a "fun" problem with MSDev.

MSDev has a nice feature of taking a snapshot of your PATH when
it is installed. From that point on it ignores the system PATH.
You can manually add new paths in Tools->Options->Directories->Executables.

-Bill

At 01:42 PM 1/7/2002 -0500, Miller, James V (CRD) wrote:

I am having a problem with the cmFLTKWrapUICommand when it is run on the PC. When fluid.exe is run, it cannot find a required dll. The specific dll is one that Intel C++ provides which is what I used to build fltk.

I can run fluid from the command line and it works fine. However, when DevStudio runs fluid as a custom command, the search path does not include the directory that has the Intel C++ dlls. This directory is in my path when I run from the comand line.

Do custom commands have a special "path" associated with them? Is this a DevStudio problem?

Jim Miller
_____________________________________
Visualization & Computer Vision
GE Corporate Research & Development
Bldg. KW, Room C218B
P.O. Box 8, Schenectady NY 12301

millerjv@crd.ge.com <mailto:millerjv@crd.ge.com>
(518) 387-4005, Dial Comm: 8*833-4005,
Cell: (518) 505-7065, Fax: (518) 387-6981

--=====================_857301003==_.ALT-- From millerjv@crd.ge.com Mon Jan 7 19:12:40 2002 From: millerjv@crd.ge.com (Miller, James V (CRD)) Date: Mon, 7 Jan 2002 14:12:40 -0500 Subject: [Cmake] What "path" do custom commands use? Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C197AF.46777770 Content-Type: text/plain Thanks. That was the problem. Is there anyway we can work around this in general? For instance, could "custom commands" for DevStudio run another program that would ferret out a good path and then exec the intended custom command executable? So instead of the custom command being: c:\itkQuality\fltk-1.0.11\fluid\fluid.exe -c -h C:/itkQuality/Continuous/Insight-intel/Examples/Morphogenesis/BacterialColonyGUI.h -o C:/itkQuality/Continuous/Insight-intel/Examples/Morphogenesis/BacterialColonyGUI.cxx c:/itkQuality/Continuous/Insight/Examples/Morphogenesis/BacterialColonyGUI.fl it would something like c:\itkQuality\CMake\hacks\fixEnviroment.bat c:\itkQuality\fltk-1.0.11\fluid\fluid.exe -c -h C:/itkQuality/Continuous/Insight-intel/Examples/Morphogenesis/BacterialColonyGUI.h -o C:/itkQuality/Continuous/Insight-intel/Examples/Morphogenesis/BacterialColonyGUI.cxx c:/itkQuality/Continuous/Insight/Examples/Morphogenesis/BacterialColonyGUI.fl It seems pretty problematic that DevStudio's environment for custom commands is not inherited. -----Original Message----- From: Bill Hoffman [mailto:bill.hoffman@kitware.com] Sent: Monday, January 07, 2002 1:54 PM To: Miller, James V (CRD); CMake developers (E-mail) Subject: Re: [Cmake] What "path" do custom commands use? This is a "fun" problem with MSDev. MSDev has a nice feature of taking a snapshot of your PATH when it is installed. From that point on it ignores the system PATH. You can manually add new paths in Tools->Options->Directories->Executables. -Bill At 01:42 PM 1/7/2002 -0500, Miller, James V (CRD) wrote: I am having a problem with the cmFLTKWrapUICommand when it is run on the PC. When fluid.exe is run, it cannot find a required dll. The specific dll is one that Intel C++ provides which is what I used to build fltk. I can run fluid from the command line and it works fine. However, when DevStudio runs fluid as a custom command, the search path does not include the directory that has the Intel C++ dlls. This directory is in my path when I run from the comand line. Do custom commands have a special "path" associated with them? Is this a DevStudio problem? Jim Miller _____________________________________ Visualization & Computer Vision GE Corporate Research & Development Bldg. KW, Room C218B P.O. Box 8, Schenectady NY 12301 millerjv@crd.ge.com < mailto:millerjv@crd.ge.com > (518) 387-4005, Dial Comm: 8*833-4005, Cell: (518) 505-7065, Fax: (518) 387-6981 ------_=_NextPart_001_01C197AF.46777770 Content-Type: text/html

Thanks. That was the problem. Is there anyway we can work around this in general? For instance, could "custom commands" for DevStudio run another program that would ferret out a good path and then exec the intended custom command executable?

So instead of the custom command being:

c:\itkQuality\fltk-1.0.11\fluid\fluid.exe -c -h C:/itkQuality/Continuous/Insight-intel/Examples/Morphogenesis/BacterialColonyGUI.h -o C:/itkQuality/Continuous/Insight-intel/Examples/Morphogenesis/BacterialColonyGUI.cxx c:/itkQuality/Continuous/Insight/Examples/Morphogenesis/BacterialColonyGUI.fl

it would something like

c:\itkQuality\CMake\hacks\fixEnviroment.bat c:\itkQuality\fltk-1.0.11\fluid\fluid.exe -c -h C:/itkQuality/Continuous/Insight-intel/Examples/Morphogenesis/BacterialColonyGUI.h -o C:/itkQuality/Continuous/Insight-intel/Examples/Morphogenesis/BacterialColonyGUI.cxx c:/itkQuality/Continuous/Insight/Examples/Morphogenesis/BacterialColonyGUI.fl

It seems pretty problematic that DevStudio's environment for custom commands is not inherited.

-----Original Message-----
From: Bill Hoffman [mailto:bill.hoffman@kitware.com]
Sent: Monday, January 07, 2002 1:54 PM
To: Miller, James V (CRD); CMake developers (E-mail)
Subject: Re: [Cmake] What "path" do custom commands use?

This is a "fun" problem with MSDev.

MSDev has a nice feature of taking a snapshot of your PATH when
it is installed. From that point on it ignores the system PATH.
You can manually add new paths in Tools->Options->Directories->Executables.

-Bill

At 01:42 PM 1/7/2002 -0500, Miller, James V (CRD) wrote:

I am having a problem with the cmFLTKWrapUICommand when it is run on the PC. When fluid.exe is run, it cannot find a required dll. The specific dll is one that Intel C++ provides which is what I used to build fltk.

I can run fluid from the command line and it works fine. However, when DevStudio runs fluid as a custom command, the search path does not include the directory that has the Intel C++ dlls. This directory is in my path when I run from the comand line.

Do custom commands have a special "path" associated with them? Is this a DevStudio problem?

Jim Miller
_____________________________________
Visualization & Computer Vision
GE Corporate Research & Development
Bldg. KW, Room C218B
P.O. Box 8, Schenectady NY 12301

millerjv@crd.ge.com <mailto:millerjv@crd.ge.com>
(518) 387-4005, Dial Comm: 8*833-4005,
Cell: (518) 505-7065, Fax: (518) 387-6981

------_=_NextPart_001_01C197AF.46777770-- From Andy.Cedilnik@kitware.com Mon Jan 7 19:18:23 2002 From: Andy.Cedilnik@kitware.com (Andy Cedilnik) Date: Mon, 07 Jan 2002 14:18:23 -0500 Subject: [Cmake] SIZEOF Feature added Message-ID: <5.1.0.14.0.20020107141259.00b1a758@pop.nycap.rr.com> Hello! Just wanted to let you know that I added a nice feature to autoconf part of CMake. It uses autoconf mechanism to get byte size of some primitive data types such as char, short, int, long, float, double and void*. The results are stored in CMake variables: CMAKE_SIZEOF_INT CMAKE_SIZEOF_SHORT .... Since Windows build systems do not use autoconf, I hardcoded these values in their files. If somebody is using Windows development tools on something with different sizes of these types, she might add support for that platform in the appropriate files. Also, when Ia64 platform becomes available, this will have to be changed. The common solution would be some equivalent to AC_RUN and AC_TRY. Andy From bill.hoffman@kitware.com Mon Jan 7 20:27:17 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Mon, 07 Jan 2002 15:27:17 -0500 Subject: [Cmake] Symbolic pathname translation In-Reply-To: <20020106151337.K11388@cs.rpi.edu> Message-ID: <5.0.2.1.0.20020107152502.08b01478@pop.nycap.rr.com> It is broken for windows now. The CMAKE path is has mixed windows and unix style paths. Getting this stuff right the first time was quite difficult. Can you back out your changes until they work on windows. -Bill At 03:13 PM 1/6/2002 -0500, Amitha Perera wrote: >Hi all > >I've just committed a change that allows the pathnames generated by >CMake to maintain symbolic links. If cmake is invoked with two >paths--the first to the source directory, the second to the output >directory--those paths will be used "as is" to refer to the roots of the >source and output trees. I call this pathname translation, and is only >enabled with this special two directory invocation. It shouldn't break >cmake for anyone. If it does, please let me know and I'll try fix it. > >To illustrate further: suppose your source and output directories are >/my/src and /my/bin, and on your machine (my.machine), these are >symbolic links to a locally mounted disk: > > my.machine: /my/src links to /localdisk/src > my.machine: /my/bin links to /localdisk/bin > >If you run CMake as normal > > cd /my/bin; cmake /my/src > >all the paths will refer to /localdisk/src and /localdisk/bin. Suppose >these disks are network mounted on a different machine (other.machine) >as > > other.machine: /my/src links to /nfs/my.machine/src > other.machine: /my/bin links to /nfs/my.machine/bin > >Then, attempting to compile the source or to run dynamically linked >executables on other.machine will fail because all references to >/localdisk are invalid. > >If, my.machine, you run CMake with pathname translation > > cd /localdisk/bin; cmake /my/src /my/bin > >Then CMake will automatically replace all references to /localdisk/src >with /my/src and to /localdisk/bin with /my/bin. Assuming /my/src and >/my/bin are valid aliases network-wide, then all is well on >other.machine. > >For pathname translation to be enabled, the symbolic source and output >directories must be absolute paths, and the output directory must >refer to the current directory. (I.e. cmake must be run from the >output directory.) > >Amitha. >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From perera@cs.rpi.edu Mon Jan 7 20:49:46 2002 From: perera@cs.rpi.edu (Amitha Perera) Date: Mon, 7 Jan 2002 15:49:46 -0500 Subject: [Cmake] Symbolic pathname translation In-Reply-To: <5.0.2.1.0.20020107152502.08b01478@pop.nycap.rr.com>; from bill.hoffman@kitware.com on Mon, Jan 07, 2002 at 03:27:17PM -0500 References: <20020106151337.K11388@cs.rpi.edu> <5.0.2.1.0.20020107152502.08b01478@pop.nycap.rr.com> Message-ID: <20020107154946.A55703@cs.rpi.edu> > Can you back out your changes until they work on windows. Done. From millerjv@crd.ge.com Tue Jan 8 15:59:18 2002 From: millerjv@crd.ge.com (Miller, James V (CRD)) Date: Tue, 8 Jan 2002 10:59:18 -0500 Subject: [Cmake] How to turn of incremental linking Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1985D.6DE3A320 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1985D.6DE3A320" ------_=_NextPart_001_01C1985D.6DE3A320 Content-Type: text/plain; charset="iso-8859-1" I am trying to build a project with the Intel C++ compiler with debug information. Occasionally, the link will fail with an internal error. When it fails, I can clean the particular project (just the exe, the supporting libraries are not rebuilt) and reproduce the error. If I toggle "incremental linking" in DevStudio, the link will succeed. So the debug information for the exe is confusing the linker when incremental linking is used. How can I specify that incremental linking should not be used for a particular build? Is this something that I can set in the CMakeCache? Jim Miller _____________________________________ Visualization & Computer Vision GE Corporate Research & Development Bldg. KW, Room C218B P.O. Box 8, Schenectady NY 12301 millerjv@crd.ge.com < mailto:millerjv@crd.ge.com > (518) 387-4005, Dial Comm: 8*833-4005, Cell: (518) 505-7065, Fax: (518) 387-6981 ------_=_NextPart_001_01C1985D.6DE3A320 Content-Type: text/html; charset="iso-8859-1"

I am trying to build a project with the Intel C++ compiler with debug information. Occasionally, the link will fail with an internal error. When it fails, I can clean the particular project (just the exe, the supporting libraries are not rebuilt) and reproduce the error. If I toggle "incremental linking" in DevStudio, the link will succeed. So the debug information for the exe is confusing the linker when incremental linking is used.

How can I specify that incremental linking should not be used for a particular build? Is this something that I can set in the CMakeCache?

------_=_NextPart_001_01C1985D.6DE3A320-- ------_=_NextPart_000_01C1985D.6DE3A320 Content-Type: application/octet-stream; name="Miller, James V (CRD).vcf" Content-Disposition: attachment; filename="Miller, James V (CRD).vcf" BEGIN:VCARD VERSION:2.1 N:Miller;James FN:Miller, James V (CRD) ORG:CRD;ESL TITLE:Computer Scientist TEL;WORK;VOICE:*833-4005 TEL;WORK;VOICE:1 518 387-4005 ADR;WORK:;KW-C218B;P.O. Box 8;Schenectady;New York;12301;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:KW-C218B=0D=0AP.O. Box 8=0D=0ASchenectady, New York 12301=0D=0AUSA EMAIL;PREF;INTERNET:millerjv@crd.ge.com REV:20010420T140329Z END:VCARD ------_=_NextPart_000_01C1985D.6DE3A320-- From Prasad.Saripalli@pnl.gov Tue Jan 8 18:20:16 2002 From: Prasad.Saripalli@pnl.gov (Saripalli, K Prasad) Date: Tue, 08 Jan 2002 10:20:16 -0800 Subject: [Cmake] VTKRENDERING.DLL Message-ID: <68105D4966353C4AB9FA8C71C22496A901210130@pnlmse16.pnl.gov> Hello Group Members, Could you please help with a simple vtk/Cmake related question. I installed vtk4.0 on my PC (Windows98) and trying to run a simple example (cone2.cxx) using Cmake, that is in tutorials/step2/cone2.cxx. I create a Cone.dsw using the Cmake. It compiles and builds fine in MS Visual Studio without any errors/warnings, but when I try to run the exe, it complains that it can't find a DLL file. A required file, VTKRENDERING.DLL was not found. Would you be able to help with this? Please let me know. Many thanks, Prasad From bill.hoffman@kitware.com Tue Jan 8 20:06:53 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Tue, 08 Jan 2002 15:06:53 -0500 Subject: [Cmake] VTKRENDERING.DLL In-Reply-To: <68105D4966353C4AB9FA8C71C22496A901210130@pnlmse16.pnl.gov> Message-ID: <5.0.2.1.0.20020108150601.00b3d0b0@pop.nycap.rr.com> This is a vtk question and should be posted to the vtkusers list. Sounds like you need to add the directory with VTKRENDERING.DLL to your PATH. -Bill At 10:20 AM 1/8/2002 -0800, Saripalli, K Prasad wrote: >Hello Group Members, > >Could you please help with a simple vtk/Cmake related question. I installed >vtk4.0 on my PC (Windows98) and trying to run a simple example (cone2.cxx) >using Cmake, that is in tutorials/step2/cone2.cxx. I create a Cone.dsw >using the Cmake. It compiles and builds fine in MS Visual Studio without >any errors/warnings, but when I try to run the exe, it complains that it >can't find a DLL file. > >A required file, VTKRENDERING.DLL was not found. > >Would you be able to help with this? Please let me know. Many thanks, > >Prasad > > > > > >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From millerjv@crd.ge.com Tue Jan 8 21:26:13 2002 From: millerjv@crd.ge.com (Miller, James V (CRD)) Date: Tue, 8 Jan 2002 16:26:13 -0500 Subject: [Cmake] How to turn of incremental linking Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1988B.199229D0 Content-Type: text/plain Thanks for adding the CMAKE_EXTRA_LINK_FLAGS. It is what I needed. It looks as though I need to set "/incremental:no /pdb:none" in order to get Insight to build Debug under Intel C++ 5.0 -----Original Message----- From: Bill Hoffman [mailto:bill.hoffman@kitware.com] Sent: Tuesday, January 08, 2002 1:33 PM To: Miller, James V (CRD) Subject: RE: [Cmake] How to turn of incremental linking Until about 5 minutes ago, you could not. If you update cmake, and add the option to this flag: CMAKE_EXTRA_LINK_FLAGS. It should fix the problem. At 01:04 PM 1/8/2002 -0500, you wrote: The default is "ON". I think I need to add /INCREMENTAL:NO to the link flags to turn off incremental linking. Unfortunately, I cannot see a way in CMake to set linker options. I found the CXX options in the CMakeCache.txt and putting /INCREMENTAL:NO there puts in the compile line but not on the link line. I think it needs to go in the DSP as # ADD LINK32 /INCREMENTAL:NO Can I do this in CMake? -----Original Message----- From: Bill Hoffman [ mailto:bill.hoffman@kitware.com ] Sent: Tuesday, January 08, 2002 12:51 PM To: Miller, James V (CRD) Subject: Re: [Cmake] How to turn of incremental linking It may just be a default. I don't see where we set it. You should do a diff on the dsp file before and after you disable it with the GUI and see what has to change. -Bill At 10:59 AM 1/8/2002 -0500, you wrote: I am trying to build a project with the Intel C++ compiler with debug information. Occasionally, the link will fail with an internal error. When it fails, I can clean the particular project (just the exe, the supporting libraries are not rebuilt) and reproduce the error. If I toggle "incremental linking" in DevStudio, the link will succeed. So the debug information for the exe is confusing the linker when incremental linking is used. How can I specify that incremental linking should not be used for a particular build? Is this something that I can set in the CMakeCache? Jim Miller _____________________________________ Visualization & Computer Vision GE Corporate Research & Development Bldg. KW, Room C218B P.O. Box 8, Schenectady NY 12301 millerjv@crd.ge.com < mailto:millerjv@crd.ge.com > (518) 387-4005, Dial Comm: 8*833-4005, Cell: (518) 505-7065, Fax: (518) 387-6981 ------_=_NextPart_001_01C1988B.199229D0 Content-Type: text/html

Thanks for adding the CMAKE_EXTRA_LINK_FLAGS. It is what I needed.

It looks as though I need to set "/incremental:no /pdb:none" in order to get Insight to build Debug under Intel C++ 5.0

-----Original Message-----
From: Bill Hoffman [mailto:bill.hoffman@kitware.com]
Sent: Tuesday, January 08, 2002 1:33 PM
To: Miller, James V (CRD)
Subject: RE: [Cmake] How to turn of incremental linking

Until about 5 minutes ago, you could not.

If you update cmake, and add the option to this flag:
CMAKE_EXTRA_LINK_FLAGS.

It should fix the problem.

At 01:04 PM 1/8/2002 -0500, you wrote:

The default is "ON". I think I need to add /INCREMENTAL:NO to the link flags to turn off incremental linking. Unfortunately,
I cannot see a way in CMake to set linker options. I found the CXX options in the CMakeCache.txt and putting /INCREMENTAL:NO there puts in the compile line but not on the link line.

I think it needs to go in the DSP as

# ADD LINK32 /INCREMENTAL:NO

Can I do this in CMake?

-----Original Message-----
From: Bill Hoffman [mailto:bill.hoffman@kitware.com]
Sent: Tuesday, January 08, 2002 12:51 PM
To: Miller, James V (CRD)
Subject: Re: [Cmake] How to turn of incremental linking

It may just be a default. I don't see where we set it.
You should do a diff on the dsp file before and after you disable it with
the GUI and see what has to change.

-Bill

At 10:59 AM 1/8/2002 -0500, you wrote:

I am trying to build a project with the Intel C++ compiler with debug information. Occasionally, the link will fail with an internal error. When it fails, I can clean the particular project (just the exe, the supporting libraries are not rebuilt) and reproduce the error. If I toggle "incremental linking" in DevStudio, the link will succeed. So the debug information for the exe is confusing the linker when incremental linking is used.

How can I specify that incremental linking should not be used for a particular build? Is this something that I can set in the CMakeCache?

Jim Miller
_____________________________________
Visualization & Computer Vision
GE Corporate Research & Development
Bldg. KW, Room C218B
P.O. Box 8, Schenectady NY 12301

millerjv@crd.ge.com <mailto:millerjv@crd.ge.com>
(518) 387-4005, Dial Comm: 8*833-4005,
Cell: (518) 505-7065, Fax: (518) 387-6981

------_=_NextPart_001_01C1988B.199229D0-- From wheeler@crd.ge.com Sat Jan 12 16:06:40 2002 From: wheeler@crd.ge.com (Wheeler, Fred (CRD)) Date: Sat, 12 Jan 2002 11:06:40 -0500 Subject: [Cmake] command to build dynamic lib changed causing my VXL build to brea k Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19B83.1EBF9E60 Content-Type: text/plain; charset="iso-8859-1" I just solved a strange build problem for myself that is somehow related to VXL, CMake and my particular environment. I don't know if there is any particular change that should be made to VXL or CMake, but this took me so long to track down I thought I should briefly report it. Sometime over the past week or two CMake started producing makefiles that use the "-shared -nostdlib" options instead of "-Wl,-G" to link objects into a shared library (*.so). With this change all of VXL still builds for me, but just about all executables produced in the VXL tree stop with a Bus Error immediately after starting. Everything build fine, but nothing runs. Strange. I'm using Solaris 2.7. I saw this problem on both gcc-3.0.3 and gcc-3.0.2. I isolated the problem (to some extent) by first backing off the compiler version, which I changed recently, then backing off the VXL source tree about a month, and then backing off the CMake source tree about a month (a desperate guess that I really didn't think would have any effect, but it did). I added these lines to my CMakeCache... CMAKE_MODULE_BUILD_FLAGS:STRING=-Wl,-G CMAKE_SHLIB_BUILD_FLAGS:STRING=-Wl,-G Fred Wheeler -- Fred Wheeler, GE CRD, KWC-303 Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) ------_=_NextPart_001_01C19B83.1EBF9E60 Content-Type: text/html; charset="iso-8859-1"

I just solved a strange build problem for myself that is somehow related to VXL, CMake and my particular environment. I don't know if there is any particular change that should be made to VXL or CMake, but this took me so long to track down I thought I should briefly report it.

Sometime over the past week or two CMake started producing makefiles that use the "-shared -nostdlib" options instead of "-Wl,-G" to link objects into a shared library (*.so). With this change all of VXL still builds for me, but just about all executables produced in the VXL tree stop with a Bus Error immediately after starting. Everything build fine, but nothing runs. Strange.

I'm using Solaris 2.7. I saw this problem on both gcc-3.0.3 and gcc-3.0.2. I isolated the problem (to some extent) by first backing off the compiler version, which I changed recently, then backing off the VXL source tree about a month, and then backing off the CMake source tree about a month (a desperate guess that I really didn't think would have any effect, but it did).

I added these lines to my CMakeCache...

CMAKE_MODULE_BUILD_FLAGS:STRING=-Wl,-G
CMAKE_SHLIB_BUILD_FLAGS:STRING=-Wl,-G

Fred Wheeler

--
Fred Wheeler, GE CRD, KWC-303
Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225)
Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042)

------_=_NextPart_001_01C19B83.1EBF9E60-- From brad.king@kitware.com Sun Jan 13 01:57:29 2002 From: brad.king@kitware.com (Brad King) Date: Sat, 12 Jan 2002 20:57:29 -0500 (EST) Subject: [Cmake] command to build dynamic lib changed causing my VXL build to brea k In-Reply-To: Message-ID: Fred, > Sometime over the past week or two CMake started producing makefiles > that use the "-shared -nostdlib" options instead of "-Wl,-G" to link > objects into a shared library (*.so). With this change all of VXL > still builds for me, but just about all executables produced in the > VXL tree stop with a Bus Error immediately after starting. > Everything build fine, but nothing runs. Strange. We recently switched the flags from -Wl,-G to -shared -nostdlib to solve other problems. The -shared flag is the correct choice..."-Wl,-G" tells the C++ compiler to pass the "-G" option to the linker, which tells it to create a shared library. However, the C++ compiler then does not know that the code it is generating is going into a shared library, so it doesn't put in the correct static data initialization code (to call constructors of static data, etc). The -shared option tells the compiler to put in the proper init code, and automatically causes it to pass the -G option on to the linker. Have you done a complete re-build of VXL in a clean directory? Your problems may be caused by some .o files or libraries being built with the old flags, and some with the new. -Brad From Peter.Vanroose@esat.kuleuven.ac.be Sun Jan 13 09:47:02 2002 From: Peter.Vanroose@esat.kuleuven.ac.be (Peter Vanroose) Date: Sun, 13 Jan 2002 10:47:02 +0100 (CET) Subject: [Cmake] Re: command to build dynamic lib changed causing my VXL build to break In-Reply-To: Message-ID: > constructors of static data, etc). The -shared option tells the compiler > to put in the proper init code, and automatically causes it to pass the -G > option on to the linker. Try adding "-v" on the compile (link) line to see what gcc really does. I've had similar problems on solaris, but in my case it was because of a missing "-nostdlib". In that case, it's exactly in the call to the global destructors that the program crash occurs: gdb test_vcl_compiler (gdb) r 0 1 Program received signal SIGSEGV, Segmentation fault. 0xef293558 in __do_global_dtors_aux () from libvcl.so which seemed to suggest that the problem lies in the extra global ctors/dtors which "-shared" adds. But when I use "-Wl,-G" instead of "-shared", it's the same. The former does collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy /gcc/.../crt1.o \ /gcc/.../crti.o /usr/ccs/lib/values-Xa.o /gcc/.../crtbegin.o \ -L... -G *.o -lgcc -lc -lgcc /gcc/.../crtend.o /gcc/.../crtn.o while the latter does: collect2 -V -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib -Qy \ /gcc/.../crti.o /usr/ccs/lib/values-Xa.o /gcc/.../crtbegin.o \ -L... *.o -lgcc_s -lgcc -lgcc_s -lgcc /gcc/.../crtend.o /gcc/.../crtn.o Now the problem (at least here) is with the -lgcc, because when I remove all -l... from the collect2 line, the shared library is less than half as large, and the program runs OK! But strange enough, when I use -nostdlib (either with -shared or -Wl,-G) also all the crt*.o disappear from the link line. Is this correct behaviour? Anyhow, most programs runs OK in both cases, but I've seen problems with std::vector initialisation, in both cases. -- Peter. From wheeler@crd.ge.com Sun Jan 13 15:01:07 2002 From: wheeler@crd.ge.com (Wheeler, Fred (CRD)) Date: Sun, 13 Jan 2002 10:01:07 -0500 Subject: [Cmake] command to build dynamic lib changed causing my VXL b uild to brea k Message-ID: Brad, Peter, Thanks for your replies. Brad's idea that I might have a mixed batch of .o files is a good one, but I guarded against that. I can demo the problem I am seeing with the commands below. I'm finding some more strange behavior described in the comments that start with "!!!". Note that optimization (whether -O2 is used or not) affects this, and that the problem only happens when I use both objects in the demo below. Brad noted that the compiler should know whether the object file it is creating will go in a shared or non-shared library. Makes sense to me, but it looks to me like cmake started using "-shared -nostdlib" for creating the shared lib, but did not change the command line for creating object files. Right? # demo cd /tmp VXLSRC=/no_backup/wheeler/prj/sr/vxl_src # !!! the problem does not occur if either of these object files is removed from the library # build vcl_ostream_iterator+int-.o c++ -g -O2 -Wall -Dvcl_EXPORTS -fPIC -I$VXLSRC/vcl -I/no_backup/wheeler/prj/sr/vxl_bld/vcl -I/no_backup/wheeler/prj/sr/vxl_bld/vxl -I$VXLSRC/vcl -DVXL_WARN_DEPRECATED -DVXL_WARN_DEPRECATED_ONCE -c $VXLSRC/vcl/Templates/vcl_ostream_iterator+int-.cxx -o vcl_ostream_iterator+int-.o # build vcl_vector+bool-.o # !!! if I remove the -O2 option - no bus error c++ -g -O2 -Wall -Dvcl_EXPORTS -fPIC -I$VXLSRC/vcl -I/no_backup/wheeler/prj/sr/vxl_bld/vcl -I/no_backup/wheeler/prj/sr/vxl_bld/vxl -I$VXLSRC/vcl -DVXL_WARN_DEPRECATED -DVXL_WARN_DEPRECATED_ONCE -c $VXLSRC/vcl/Templates/vcl_vector+bool-.cxx -o vcl_vector+bool-.o # a minimal main cat<| foo.cxx int main() { return 0; } EOF c++ -g -O2 -c foo.cxx -o foo.o # with this option there is no bus error OPT="-Wl,-G" # with this option the exec will produce a bus error OPT="-shared -nostdlib" # build vcl library with only two objects c++ -v $OPT -g -O2 -o /tmp/libvcl.so \ vcl_ostream_iterator+int-.o \ vcl_vector+bool-.o # link c++ foo.o -L/tmp -lvcl -Wl,-R,/tmp: -o foo # run, bus error will occur here is "-shared -nostdlib" was used ./foo # if there was a bus error, gdb yeilds garbage (otherwise it works) 138% gdb foo GNU gdb 5.1 (gdb) break main Breakpoint 1 at 0x10700: file foo.cxx, line 1. (gdb) run Starting program: /tmp/foo Program received signal SIGSEGV, Segmentation fault. 0xff3c9e84 in ?? () (gdb) where #0 0xff3c9e84 in ?? () #1 0xff3c3bdc in ?? () #2 0xff3b2ea0 in ?? () #3 0xff3ba8cc in ?? () #4 0xff3c4da0 in ?? () #5 0xff3b2958 in ?? () (gdb) Fred Wheeler -- Fred Wheeler, GE CRD, KWC-303 Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) -----Original Message----- From: Brad King [mailto:brad.king@kitware.com] Sent: Saturday, January 12, 2002 8:57 PM To: Wheeler, Fred (CRD) Cc: 'vxl-maintainers@lists.sourceforge.net'; 'cmake@public.kitware.com' Subject: Re: [Cmake] command to build dynamic lib changed causing my VXL build to brea k Fred, > Sometime over the past week or two CMake started producing makefiles > that use the "-shared -nostdlib" options instead of "-Wl,-G" to link > objects into a shared library (*.so). With this change all of VXL > still builds for me, but just about all executables produced in the > VXL tree stop with a Bus Error immediately after starting. > Everything build fine, but nothing runs. Strange. We recently switched the flags from -Wl,-G to -shared -nostdlib to solve other problems. The -shared flag is the correct choice..."-Wl,-G" tells the C++ compiler to pass the "-G" option to the linker, which tells it to create a shared library. However, the C++ compiler then does not know that the code it is generating is going into a shared library, so it doesn't put in the correct static data initialization code (to call constructors of static data, etc). The -shared option tells the compiler to put in the proper init code, and automatically causes it to pass the -G option on to the linker. Have you done a complete re-build of VXL in a clean directory? Your problems may be caused by some .o files or libraries being built with the old flags, and some with the new. -Brad From billlist@nycap.rr.com Sun Jan 13 16:41:07 2002 From: billlist@nycap.rr.com (William A. Hoffman) Date: Sun, 13 Jan 2002 11:41:07 -0500 Subject: [Vxl-maintainers] RE: [Cmake] command to build dynamic lib changed causing my VXL b uild to brea k In-Reply-To: Message-ID: <5.0.2.1.0.20020113113322.02d013c0@pop.nycap.rr.com> This could be a bad installation of gcc on your solaris machine. The only thing that changed was the creation of shared libraries. You are right in saying that the .o files are created in the same way. With the -shared option the compiler knows it is creating a shared library, so it can put calls to initialize global objects in the init section of the shared library. The compilation of .o files has not been changed. The -nostdlib tells the compiler not to link in libstdc++ or libc as these are often not shared libraries and linking in static ones with a shared library would cause link errors. So you are getting a crash in an object initialization which was not happening before. Does it matter what is in the shared library. You said this crashed: c++ -v $OPT -g -O2 -o /tmp/libvcl.so \ vcl_ostream_iterator+int-.o \ vcl_vector+bool-.o What about: foo.o where foo has one function in it. If that crashes, I am suspecting your gcc installation. VTK is working fine with these flags. One more thing, can you leave off the -O2 -g and just use -g, that compiler option has caused me trouble before, also you might get a call stack in the debugger. -Bill At 10:01 AM 1/13/2002 -0500, Wheeler, Fred (CRD) wrote: >Brad, Peter, > >Thanks for your replies. Brad's idea that I might have a mixed batch of >.o files is a good one, but >I guarded against that. I can demo the problem I am seeing with the >commands below. I'm finding >some more strange behavior described in the comments that start with >"!!!". Note that optimization >(whether -O2 is used or not) affects this, and that the problem only >happens when I use both objects >in the demo below. > >Brad noted that the compiler should know whether the object file it is >creating will go in a shared >or non-shared library. Makes sense to me, but it looks to me like cmake >started using "-shared >-nostdlib" for creating the shared lib, but did not change the command >line for creating object >files. Right? > ># demo >cd /tmp >VXLSRC=/no_backup/wheeler/prj/sr/vxl_src > ># !!! the problem does not occur if either of these object files is >removed from the library > ># build vcl_ostream_iterator+int-.o >c++ -g -O2 -Wall -Dvcl_EXPORTS -fPIC -I$VXLSRC/vcl >-I/no_backup/wheeler/prj/sr/vxl_bld/vcl >-I/no_backup/wheeler/prj/sr/vxl_bld/vxl -I$VXLSRC/vcl -DVXL_WARN_DEPRECATED >-DVXL_WARN_DEPRECATED_ONCE -c >$VXLSRC/vcl/Templates/vcl_ostream_iterator+int-.cxx -o >vcl_ostream_iterator+int-.o > ># build vcl_vector+bool-.o ># !!! if I remove the -O2 option - no bus error >c++ -g -O2 -Wall -Dvcl_EXPORTS -fPIC -I$VXLSRC/vcl >-I/no_backup/wheeler/prj/sr/vxl_bld/vcl >-I/no_backup/wheeler/prj/sr/vxl_bld/vxl -I$VXLSRC/vcl -DVXL_WARN_DEPRECATED >-DVXL_WARN_DEPRECATED_ONCE -c $VXLSRC/vcl/Templates/vcl_vector+bool-.cxx >-o vcl_vector+bool-.o > ># a minimal main >cat<| foo.cxx >int main() { return 0; } >EOF > >c++ -g -O2 -c foo.cxx -o foo.o > ># with this option there is no bus error >OPT="-Wl,-G" ># with this option the exec will produce a bus error >OPT="-shared -nostdlib" > ># build vcl library with only two objects >c++ -v $OPT -g -O2 -o /tmp/libvcl.so \ > vcl_ostream_iterator+int-.o \ > vcl_vector+bool-.o > ># link >c++ foo.o -L/tmp -lvcl -Wl,-R,/tmp: -o foo > ># run, bus error will occur here is "-shared -nostdlib" was used >./foo > ># if there was a bus error, gdb yeilds garbage (otherwise it works) >138% gdb foo >GNU gdb 5.1 >(gdb) break main >Breakpoint 1 at 0x10700: file foo.cxx, line 1. >(gdb) run >Starting program: /tmp/foo > >Program received signal SIGSEGV, Segmentation fault. >0xff3c9e84 in ?? () >(gdb) where >#0 0xff3c9e84 in ?? () >#1 0xff3c3bdc in ?? () >#2 0xff3b2ea0 in ?? () >#3 0xff3ba8cc in ?? () >#4 0xff3c4da0 in ?? () >#5 0xff3b2958 in ?? () >(gdb) From brad.king@kitware.com Sun Jan 13 16:57:32 2002 From: brad.king@kitware.com (Brad King) Date: Sun, 13 Jan 2002 11:57:32 -0500 (EST) Subject: [Vxl-maintainers] RE: [Cmake] command to build dynamic lib changed causing my VXL b uild to brea k In-Reply-To: <5.0.2.1.0.20020113113322.02d013c0@pop.nycap.rr.com> Message-ID: Fred, Peter, Bill, > This could be a bad installation of gcc on your solaris machine. > The only thing that changed was the creation of shared libraries. > You are right in saying that the .o files are created in the same way. I have duplicated the problem using our correct installation of gcc 2.95.2 on our solaris machine by following Fred's instructions. The foo executable core dumps immediately if -shared -nostdlib is used. One difference, though, is that -Wl,-G seems to produce an executable that gets in an infinite loop. I'm working on it... -Brad From brad.king@kitware.com Sun Jan 13 17:33:08 2002 From: brad.king@kitware.com (Brad King) Date: Sun, 13 Jan 2002 12:33:08 -0500 (EST) Subject: [Vxl-maintainers] RE: [Cmake] command to build dynamic lib changed causing my VXL b uild to brea k In-Reply-To: Message-ID: > Fred, Peter, Bill, > > > This could be a bad installation of gcc on your solaris machine. > > The only thing that changed was the creation of shared libraries. > > You are right in saying that the .o files are created in the same way. > I have duplicated the problem using our correct installation of gcc 2.95.2 > on our solaris machine by following Fred's instructions. > > The foo executable core dumps immediately if -shared -nostdlib is used. > One difference, though, is that -Wl,-G seems to produce an executable that > gets in an infinite loop. I'm working on it... Well, I must have mixed up some flags or something before, because I can't duplicate the problem anymore. Either set of flags produces an executable that returns immediately without an error. Fred, I would suggest you try what Bill suggested. -Brad From bill.hoffman@kitware.com Mon Jan 14 15:53:30 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Mon, 14 Jan 2002 10:53:30 -0500 Subject: [Cmake] MS Project dsp regeneration Message-ID: <5.0.2.1.0.20020114104829.037c7f38@pop.nycap.rr.com> Hi, I am thinking of removing the dependances on the CMakeLists.txt files to generate the .dsp files from cmake. This would mean that: 1. if a CMakeLists.txt file changed and you did a build in MSDev you could possibly have out of date dsp files. ( you would always have to run cmake outside of msdev when a CMakeLists.txt file changed.) 2. You could use the Clean and ReBuild all options on MSDeve without being inundated with the "dsp file has changed on disk would you like to reload?" questions. It seems that this feature of cmake is more trouble than it is worth. If there was some way to avoid MSDev asking the question, and automatically reloading, that would be greate, but I don't think there is. -Bill From ian.m.scott@stud.man.ac.uk Mon Jan 14 15:58:58 2002 From: ian.m.scott@stud.man.ac.uk (Ian Scott) Date: Mon, 14 Jan 2002 15:58:58 -0000 Subject: [Cmake] MS Project dsp regeneration In-Reply-To: <5.0.2.1.0.20020114104829.037c7f38@pop.nycap.rr.com> Message-ID: <000201c19d14$612b02c0$22ea5882@ian> Bill, I've got used to being able to force a rebuild of the dsp files from inside DevStudio. Perhaps you could have an CMake option controlling the dependencies? Ian. > -----Original Message----- > From: Bill Hoffman [mailto:bill.hoffman@kitware.com] > Sent: Monday, January 14, 2002 3:54 PM > To: cmake@public.kitware.com > Subject: [Cmake] MS Project dsp regeneration > > > Hi, > > I am thinking of removing the dependances on the > CMakeLists.txt files to > generate the .dsp files from cmake. > > This would mean that: > > 1. if a CMakeLists.txt file changed and you did a build in > MSDev you could > possibly have out of date dsp files. ( you would always have > to run cmake outside > of msdev when a CMakeLists.txt file changed.) > > 2. You could use the Clean and ReBuild all options on MSDeve > without being > inundated with the "dsp file has changed on disk would you > like to reload?" questions. > > > It seems that this feature of cmake is more trouble than it is worth. > If there was some way to avoid MSDev asking the question, and > automatically reloading, > that would be greate, but I don't think there is. > > > -Bill > > > _______________________________________________ > Cmake mailing list > Cmake@public.kitware.com > http://public.kitware.com/mailman/listinfo/cmake > From perera@cs.rpi.edu Mon Jan 14 16:01:48 2002 From: perera@cs.rpi.edu (Amitha Perera) Date: Mon, 14 Jan 2002 11:01:48 -0500 Subject: [Cmake] MS Project dsp regeneration In-Reply-To: <5.0.2.1.0.20020114104829.037c7f38@pop.nycap.rr.com>; from bill.hoffman@kitware.com on Mon, Jan 14, 2002 at 10:53:30AM -0500 References: <5.0.2.1.0.20020114104829.037c7f38@pop.nycap.rr.com> Message-ID: <20020114110148.D36831@cs.rpi.edu> > 2. You could use the Clean and ReBuild all options on MSDeve without being > inundated with the "dsp file has changed on disk would you like to > reload?" questions. Couldn't you avoid this by actually writing the .dsp if and only if the contents change? For example, the DSPWriter could write to a temporary file, then compare the original with the new, and update the original only if necessary. This would give flexibility, so that you are prompted for reloading only when you've actually made a change that warrants reloading. Previously, a number of out users have run into "problems" because the DSP did not reflect the CMakeLists.txt. Being able to edit the file within VS, and having the change take effect immediately went a long way toward solving those issues. [ However, I don't develop under VS, so my opinion is probably not worth much. :-) ] Amitha. From millerjv@crd.ge.com Mon Jan 14 16:11:40 2002 From: millerjv@crd.ge.com (Miller, James V (CRD)) Date: Mon, 14 Jan 2002 11:11:40 -0500 Subject: [Cmake] MS Project dsp regeneration Message-ID: I like this suggestion. It makes sense to me that cmake should avoid overwriting the existing dsp if nothing "changed". Does a DevStudio "Clean" wipe out the current dsp's in the workspace? -----Original Message----- From: Amitha Perera [mailto:perera@cs.rpi.edu] Sent: Monday, January 14, 2002 11:02 AM To: Bill Hoffman Cc: cmake@public.kitware.com Subject: Re: [Cmake] MS Project dsp regeneration > 2. You could use the Clean and ReBuild all options on MSDeve without being > inundated with the "dsp file has changed on disk would you like to > reload?" questions. Couldn't you avoid this by actually writing the .dsp if and only if the contents change? For example, the DSPWriter could write to a temporary file, then compare the original with the new, and update the original only if necessary. This would give flexibility, so that you are prompted for reloading only when you've actually made a change that warrants reloading. Previously, a number of out users have run into "problems" because the DSP did not reflect the CMakeLists.txt. Being able to edit the file within VS, and having the change take effect immediately went a long way toward solving those issues. [ However, I don't develop under VS, so my opinion is probably not worth much. :-) ] Amitha. _______________________________________________ Cmake mailing list Cmake@public.kitware.com http://public.kitware.com/mailman/listinfo/cmake From bill.hoffman@kitware.com Mon Jan 14 16:28:43 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Mon, 14 Jan 2002 11:28:43 -0500 Subject: [Cmake] MS Project dsp regeneration In-Reply-To: <20020114110148.D36831@cs.rpi.edu> References: <5.0.2.1.0.20020114104829.037c7f38@pop.nycap.rr.com> <5.0.2.1.0.20020114104829.037c7f38@pop.nycap.rr.com> Message-ID: <5.0.2.1.0.20020114111722.022d6c40@pop.nycap.rr.com> At 11:01 AM 1/14/2002 -0500, Amitha Perera wrote: >> 2. You could use the Clean and ReBuild all options on MSDeve without being >> inundated with the "dsp file has changed on disk would you like to >> reload?" questions. > >Couldn't you avoid this by actually writing the .dsp if and only if >the contents change? For example, the DSPWriter could write to a >temporary file, then compare the original with the new, and update the >original only if necessary. This would give flexibility, so that you >are prompted for reloading only when you've actually made a change >that warrants reloading. If I did that, it would be running cmake all the time because the target would never be up-to-date. However, we might be able to use the pre-link or post-build rule in the dsp file. It would be fired off every time, and we could write a cmake executable that checked the time stamps on the dsp and the CMakeList.txt files that generated it, and it could do the write only if change on the dsp file. I guess the post-build would be the best place. Currently, you have to build it twice anyway, for the re-load to happen. -Bill From bill.hoffman@kitware.com Mon Jan 14 16:30:38 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Mon, 14 Jan 2002 11:30:38 -0500 Subject: [Cmake] MS Project dsp regeneration In-Reply-To: Message-ID: <5.0.2.1.0.20020114112940.03ce4c58@pop.nycap.rr.com> At 11:11 AM 1/14/2002 -0500, Miller, James V (CRD) wrote: >I like this suggestion. It makes sense to me that cmake should avoid overwriting the existing dsp if >nothing "changed". It would always run that rule because the .dsp files would never catch up. >Does a DevStudio "Clean" wipe out the current dsp's in the workspace? Yes, the clean wipes out all the dsp files. >-----Original Message----- >From: Amitha Perera [mailto:perera@cs.rpi.edu] >Sent: Monday, January 14, 2002 11:02 AM >To: Bill Hoffman >Cc: cmake@public.kitware.com >Subject: Re: [Cmake] MS Project dsp regeneration > > >> 2. You could use the Clean and ReBuild all options on MSDeve without being >> inundated with the "dsp file has changed on disk would you like to >> reload?" questions. > >Couldn't you avoid this by actually writing the .dsp if and only if >the contents change? For example, the DSPWriter could write to a >temporary file, then compare the original with the new, and update the >original only if necessary. This would give flexibility, so that you >are prompted for reloading only when you've actually made a change >that warrants reloading. > >Previously, a number of out users have run into "problems" because the >DSP did not reflect the CMakeLists.txt. Being able to edit the file >within VS, and having the change take effect immediately went a long >way toward solving those issues. > >[ However, I don't develop under VS, so my opinion is probably not >worth much. :-) ] > >Amitha. >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From bill.hoffman@kitware.com Mon Jan 14 16:37:31 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Mon, 14 Jan 2002 11:37:31 -0500 Subject: [Cmake] MS Project dsp regeneration In-Reply-To: <5.0.2.1.0.20020114112940.03ce4c58@pop.nycap.rr.com> References: Message-ID: <5.0.2.1.0.20020114113654.022b6470@pop.nycap.rr.com> > > >>Does a DevStudio "Clean" wipe out the current dsp's in the workspace? > >Yes, the clean wipes out all the dsp files. It wipes them out if there are rules to build them like we have done in cmake generated dsp files. -Bill From perera@cs.rpi.edu Mon Jan 14 16:43:08 2002 From: perera@cs.rpi.edu (Amitha Perera) Date: Mon, 14 Jan 2002 11:43:08 -0500 Subject: [Cmake] MS Project dsp regeneration In-Reply-To: <5.0.2.1.0.20020114113654.022b6470@pop.nycap.rr.com>; from bill.hoffman@kitware.com on Mon, Jan 14, 2002 at 11:37:31AM -0500 References: <5.0.2.1.0.20020114112940.03ce4c58@pop.nycap.rr.com> <5.0.2.1.0.20020114113654.022b6470@pop.nycap.rr.com> Message-ID: <20020114114308.I36831@cs.rpi.edu> > It wipes them out if there are rules to build them like we have done in cmake > generated dsp files. How about having a build rule to build MyProject.dsp.cmake instead of MyProject.dsp? CMake will generate this file, compare the contents with an existing MyProject.dsp, and will overwrite MyProject.dsp if necessary. This way, VS does not know that the dsps are autogenerated, and won't wipe them. When the CMakeLists.txt changes, it'll be newer than MyProject.dsp.cmake, so that will be regenerated, which will in turn cause the corresponding .dsp to be updated, and only that project need be reloaded. From billlist@nycap.rr.com Mon Jan 14 16:57:58 2002 From: billlist@nycap.rr.com (William A. Hoffman) Date: Mon, 14 Jan 2002 11:57:58 -0500 Subject: [Vxl-maintainers] RE: [Cmake] command to build dynamic lib ch anged causing my VXL b uild to brea k In-Reply-To: Message-ID: <5.0.2.1.0.20020114115013.03d01a58@pop.nycap.rr.com> So, it is just vcl_ostream_iterator+int-.o and vcl_vector+bool-.o that cause the trouble? HMMMM..... I was looking at these two files and found this: #if !defined(VCL_SGI_CC) && !defined(WIN32) && !defined(GNU_LIBSTDCXX_V3) template class vcl_ostream_iterator; #endif // SunPro 5.0 provides vector as a specialization of vector. // Ditto for GNU lib v3. namespace { void tic(int nargs) { vcl_vector done_once(nargs, false); } If you notice, these files should be empty for LIBSTDCXX_V3 which is what I think that GCC 3.0 uses. However, I bet that this: GNU_LIBSTDCXX_V3 is not defined. So, I think the bug may be in vcl and not cmake. Both of these files should be empty for the compiler/library you are using, but apparently they are not.... -Bill At 11:00 AM 1/14/2002 -0500, you wrote: >I have not found out anything new that helps. > >I realized this morning that I was compiling on Solaris 2.8, but had built gcc on Solaris 2.7. But, >no luck, I was able to repeat the problem this morning on 2.7. > >As I noted earlier, turning off -O2 fixes the problem. Also, which objects are put into the shared >lib affects the problem. In my demo I built the shared lib with two object files. If I eliminated >either one the problem went away. So, it seems to be just those objects, or some combination of >them. I hope that is helpful to you. Does this make you think compiler problem? > >Fred Wheeler > >-- >Fred Wheeler, GE CRD, KWC-303 >Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) >Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) > > >-----Original Message----- >From: William A. Hoffman [mailto:billlist@nycap.rr.com] >Sent: Monday, January 14, 2002 10:48 AM >To: Wheeler, Fred (CRD) >Subject: Re: [Vxl-maintainers] RE: [Cmake] command to build dynamic lib >changed causing my VXL b uild to brea k > > >Have you found any thing else about this problem? > >Is it just those vcl objects, or is it any objects? > >We would like to make a cmake release soon, so I would like to clear this up ASAP. > >-Bill > > >At 10:01 AM 1/13/2002 -0500, you wrote: >>Brad, Peter, >> >>Thanks for your replies. Brad's idea that I might have a mixed batch of .o files is a good one, but >>I guarded against that. I can demo the problem I am seeing with the commands below. I'm finding >>some more strange behavior described in the comments that start with "!!!". Note that optimization >>(whether -O2 is used or not) affects this, and that the problem only happens when I use both objects >>in the demo below. >> >>Brad noted that the compiler should know whether the object file it is creating will go in a shared >>or non-shared library. Makes sense to me, but it looks to me like cmake started using "-shared >>-nostdlib" for creating the shared lib, but did not change the command line for creating object >>files. Right? >> >># demo >>cd /tmp >>VXLSRC=/no_backup/wheeler/prj/sr/vxl_src >> >># !!! the problem does not occur if either of these object files is removed from the library >> >># build vcl_ostream_iterator+int-.o >>c++ -g -O2 -Wall -Dvcl_EXPORTS -fPIC -I$VXLSRC/vcl -I/no_backup/wheeler/prj/sr/vxl_bld/vcl >>-I/no_backup/wheeler/prj/sr/vxl_bld/vxl -I$VXLSRC/vcl -DVXL_WARN_DEPRECATED >>-DVXL_WARN_DEPRECATED_ONCE -c $VXLSRC/vcl/Templates/vcl_ostream_iterator+int-.cxx -o >>vcl_ostream_iterator+int-.o >> >># build vcl_vector+bool-.o >># !!! if I remove the -O2 option - no bus error >>c++ -g -O2 -Wall -Dvcl_EXPORTS -fPIC -I$VXLSRC/vcl -I/no_backup/wheeler/prj/sr/vxl_bld/vcl >>-I/no_backup/wheeler/prj/sr/vxl_bld/vxl -I$VXLSRC/vcl -DVXL_WARN_DEPRECATED >>-DVXL_WARN_DEPRECATED_ONCE -c $VXLSRC/vcl/Templates/vcl_vector+bool-.cxx -o vcl_vector+bool-.o >> >># a minimal main >>cat<| foo.cxx >>int main() { return 0; } >>EOF >> >>c++ -g -O2 -c foo.cxx -o foo.o >> >># with this option there is no bus error >>OPT="-Wl,-G" >># with this option the exec will produce a bus error >>OPT="-shared -nostdlib" >> >># build vcl library with only two objects >>c++ -v $OPT -g -O2 -o /tmp/libvcl.so \ >> vcl_ostream_iterator+int-.o \ >> vcl_vector+bool-.o >> >># link >>c++ foo.o -L/tmp -lvcl -Wl,-R,/tmp: -o foo >> >># run, bus error will occur here is "-shared -nostdlib" was used >>./foo >> >># if there was a bus error, gdb yeilds garbage (otherwise it works) >>138% gdb foo >>GNU gdb 5.1 >>(gdb) break main >>Breakpoint 1 at 0x10700: file foo.cxx, line 1. >>(gdb) run >>Starting program: /tmp/foo >> >>Program received signal SIGSEGV, Segmentation fault. >>0xff3c9e84 in ?? () >>(gdb) where >>#0 0xff3c9e84 in ?? () >>#1 0xff3c3bdc in ?? () >>#2 0xff3b2ea0 in ?? () >>#3 0xff3ba8cc in ?? () >>#4 0xff3c4da0 in ?? () >>#5 0xff3b2958 in ?? () >>(gdb) >> >> >>Fred Wheeler >> >>-- >>Fred Wheeler, GE CRD, KWC-303 >>Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) >>Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) >> >> >>-----Original Message----- >>From: Brad King [mailto:brad.king@kitware.com] >>Sent: Saturday, January 12, 2002 8:57 PM >>To: Wheeler, Fred (CRD) >>Cc: 'vxl-maintainers@lists.sourceforge.net'; 'cmake@public.kitware.com' >>Subject: Re: [Cmake] command to build dynamic lib changed causing my VXL >>build to brea k >> >> >>Fred, >> >>> Sometime over the past week or two CMake started producing makefiles >>> that use the "-shared -nostdlib" options instead of "-Wl,-G" to link >>> objects into a shared library (*.so). With this change all of VXL >>> still builds for me, but just about all executables produced in the >>> VXL tree stop with a Bus Error immediately after starting. >>> Everything build fine, but nothing runs. Strange. >>We recently switched the flags from -Wl,-G to -shared -nostdlib to solve >>other problems. The -shared flag is the correct choice..."-Wl,-G" tells >>the C++ compiler to pass the "-G" option to the linker, which tells it to >>create a shared library. However, the C++ compiler then does not know >>that the code it is generating is going into a shared library, so it >>doesn't put in the correct static data initialization code (to call >>constructors of static data, etc). The -shared option tells the compiler >>to put in the proper init code, and automatically causes it to pass the -G >>option on to the linker. >> >>Have you done a complete re-build of VXL in a clean directory? Your >>problems may be caused by some .o files or libraries being built with the >>old flags, and some with the new. >> >>-Brad >> >>_______________________________________________ >>Vxl-maintainers mailing list >>Vxl-maintainers@lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/vxl-maintainers From bill.hoffman@kitware.com Tue Jan 15 03:20:43 2002 From: bill.hoffman@kitware.com (William A. Hoffman) Date: Mon, 14 Jan 2002 22:20:43 -0500 Subject: [Cmake] MS Project dsp regeneration In-Reply-To: <20020114114308.I36831@cs.rpi.edu> References: <5.0.2.1.0.20020114113654.022b6470@pop.nycap.rr.com> <5.0.2.1.0.20020114112940.03ce4c58@pop.nycap.rr.com> <5.0.2.1.0.20020114113654.022b6470@pop.nycap.rr.com> Message-ID: <5.0.2.1.0.20020114221942.02d0e008@pop.nycap.rr.com> Ok, this seems to work, I have checked in this change. You can actually do Clean and ReBuild in MsDev without having to answer a bunch of dialogs. -Bill At 11:43 AM 1/14/2002 -0500, Amitha Perera wrote: > > It wipes them out if there are rules to build them like we have done in > cmake > > generated dsp files. > >How about having a build rule to build MyProject.dsp.cmake instead of >MyProject.dsp? CMake will generate this file, compare the contents >with an existing MyProject.dsp, and will overwrite MyProject.dsp if >necessary. This way, VS does not know that the dsps are autogenerated, >and won't wipe them. When the CMakeLists.txt changes, it'll be newer >than MyProject.dsp.cmake, so that will be regenerated, which will in >turn cause the corresponding .dsp to be updated, and only that project >need be reloaded. >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From wheeler@crd.ge.com Tue Jan 15 20:04:36 2002 From: wheeler@crd.ge.com (Wheeler, Fred (CRD)) Date: Tue, 15 Jan 2002 15:04:36 -0500 Subject: [Cmake] CMake string matching in an IF condition Message-ID: Is something like the MATCHES line below possible in CMake? Can I test whether two strings are (not) equal? The manual is not clear on the subject. I'd like to scan the BUILD dir for CMakeListsLocal to keep the source dir pure, but I don't want to include CMakeListsLocal twice. # This line is already in VXLSRC/CMakeLists.txt INCLUDE( ${allvxl_SOURCE_DIR}/CMakeListsLocal.txt OPTIONAL ) # The rest is new, and I think useful # include CMakeListsLocal.txt from BUILD dir if not the same as SOURCE IF( NOT ${allvxl_BUILD_DIR} MATCHES ${allvxl_SOURCE_DIR} ) INCLUDE( ${allvxl_BUILD_DIR}/CMakeListsLocal.txt OPTIONAL ) ENDIF Thanks, Fred Wheeler -- Fred Wheeler, GE CRD, KWC-303 Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) From bill.hoffman@kitware.com Tue Jan 15 22:27:51 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Tue, 15 Jan 2002 17:27:51 -0500 Subject: [Cmake] CMake string matching in an IF condition In-Reply-To: Message-ID: <5.0.2.1.0.20020115172612.03c9efd0@pop.nycap.rr.com> The NOT part will not work. However, you can have an empty IF, so it would be: IF( ${allvxl_BUILD_DIR} MATCHES ${allvxl_SOURCE_DIR} ) ELSE( ${allvxl_BUILD_DIR} MATCHES ${allvxl_SOURCE_DIR} ) INCLUDE( ${allvxl_BUILD_DIR}/CMakeListsLocal.txt OPTIONAL ) ENDIF At 03:04 PM 1/15/2002 -0500, Wheeler, Fred (CRD) wrote: >Is something like the MATCHES line below possible in CMake? Can I test whether two strings are (not) >equal? The manual is not clear on the subject. I'd like to scan the BUILD dir for CMakeListsLocal >to keep the source dir pure, but I don't want to include CMakeListsLocal twice. > ># This line is already in VXLSRC/CMakeLists.txt >INCLUDE( ${allvxl_SOURCE_DIR}/CMakeListsLocal.txt OPTIONAL ) ># The rest is new, and I think useful ># include CMakeListsLocal.txt from BUILD dir if not the same as SOURCE >IF( NOT ${allvxl_BUILD_DIR} MATCHES ${allvxl_SOURCE_DIR} ) > INCLUDE( ${allvxl_BUILD_DIR}/CMakeListsLocal.txt OPTIONAL ) >ENDIF > >Thanks, >Fred Wheeler > >-- >Fred Wheeler, GE CRD, KWC-303 >Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) >Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From bill.hoffman@kitware.com Wed Jan 16 18:53:55 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Wed, 16 Jan 2002 13:53:55 -0500 Subject: [Cmake] CMake 1.2 Released Message-ID: <5.0.2.1.0.20020116130246.03d63578@pop.nycap.rr.com> --=====================_1634816902==_.ALT Content-Type: text/plain; charset="us-ascii" I would like to announce the release of CMake version 1.2. You can download binaries or source distributions from http://www.cmake.org/CMake/HTML/Download.html. You can also use the "Check for Updates" option from a previous windows binary installation. If you are using the cvs tree for ITK or VTK, then you should upgrade to CMake1.2. Summary of Changes: CMake now is much more selective about creating new dsp files significantly reducing the number of reloads done in Visual Studio. A new option to the IF command was added that tests if a file exists: IF (EXISTS filename) A number of fixes were added to the boreland and nmake build options. Borland now supports building shared and static libraries. A fix to the FIND_PATH command that could cause cmake to think the cache is always changing. Added CMAKE_EXTRA_LINK_FLAGS so that flags can be passed specifically to the linker. Enhancements to many modules and templates. Borland dll builds work. AIX shared libraries work with gcc. UNIX dependances are kept up-to-date. -Bill Hoffman --=====================_1634816902==_.ALT Content-Type: text/html; charset="us-ascii" I would like to announce the release of CMake version 1.2. You can download binaries or source distributions from
http://www.cmake.org/CMake/HTML/Download.html. You can also use the "Check for Updates" option from a previous
windows binary installation. If you are using the cvs tree for ITK or VTK, then you should upgrade to CMake1.2.

Summary of Changes:

CMake now is much more selective about creating new dsp files significantly reducing the number of reloads done in Visual Studio. A new option to the IF command was added that tests if a file exists: IF (EXISTS filename) A number of fixes were added to the boreland and nmake build options. Borland now supports building shared and static libraries. A fix to the FIND_PATH command that could cause cmake to think the cache is always changing. Added CMAKE_EXTRA_LINK_FLAGS so that flags can be passed specifically to the linker. Enhancements to many modules and templates. Borland dll builds work. AIX shared libraries work with gcc. UNIX dependances are kept up-to-date.

-Bill Hoffman

--=====================_1634816902==_.ALT-- From herc@schrodinger.com Thu Jan 17 02:18:17 2002 From: herc@schrodinger.com (Silverstein) Date: Wed, 16 Jan 2002 18:18:17 -0800 Subject: [Cmake] can't build on aix Message-ID: <3C463469.F4831B4F@schrodinger.com> I just downloaded cmake and tried to build on aix 4.3.3 with the visual age 5.0 c++ compiler. But it fails to build. I set CXX=/usr/bin/xlC. Is this code ANSI C++ compliant (not sure this is the issue but we have had this issue with other stuff recently)? Is there some sort of work-around? Thanks, Herc ./configure loading cache ./config.cache checking for gcc... no checking for cc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cc accepts -g... yes checking for c++... /usr/bin/xlC checking whether the C++ compiler (/usr/bin/xlC ) works... yes checking whether the C++ compiler (/usr/bin/xlC ) is a cross-compiler... no checking whether we are using GNU C++... no checking whether /usr/bin/xlC accepts -g... yes checking system version (for dynamic loading)... AIX-3 checking ansi standard C++ stream headers ... yes checking ansi standard namespace support ... yes checking ansi for scope support ... yes checking for gmake... no checking for make... /usr/bin/make updating cache ./config.cache creating ./config.status creating Source/InitialConfigureFlags.cmake creating Makefile creating Source/Makefile creating Source/cmConfigure.h cd Source; make /usr/bin/xlC -DCMAKE_ROOT_DIR='"/home/herc/surf/CMake-1-2"' -g -DCMAKE_HAS_AUTOCONF -I/home/herc/surf/CMake-1-2/Source -c cmake.cxx -o cmake.o "cmUnixMakefileGenerator.h", line 111.50: 1540-0040 (S) The text "&" is unexpected. "cmMakeDepend" may be undeclared or ambiguous. make: The error code from the last command is 1. Stop. make: The error code from the last command is 2. Stop. ./configure[1417]: ./Source/cmake: not found make: Cannot find a rule to create target depend from dependencies. Stop. From geoff@robots.ox.ac.uk Thu Jan 17 11:12:41 2002 From: geoff@robots.ox.ac.uk (Geoffrey Cross) Date: Thu, 17 Jan 2002 11:12:41 -0000 Subject: [Cmake] Default output name for DLL Message-ID: <000201c19f47$e23a98f0$bb0c14ac@smirnov> I just did a cvs update, and have now got a whole range of little problems, the most puzzling being: I am building a bunch of dlls, which worked just fine under my previous cmake installation (dating back to around the beginning of December). The relevant line in my CMakeLists is: ADD_LIBRARY(something SHARED something_sources) In order to get the correct entry point, something_sources also needed to include a .def file containing just the line: EXPORTS entry_point_function_name However, for some unknown reason, this no longer works and I get the standard LNK1561 (entry point not defined) error. Finally, I found that the .def file now needs to include the library name: LIBRARY something EXPORTS entry_point_function_name That's solved, but I'm confused as to why this is necessary now, but previously it wasn't (it also makes things slightly less pretty, as I used to include the same .def file to generate a whole range of DLLS all with the same entry point). More annoying, however, is that for some reason the DLL generated now has a .exe extension! If I rename it to *.dll, everything works just fine, but why!???! Geoff. From ian.m.scott@stud.man.ac.uk Thu Jan 17 11:15:34 2002 From: ian.m.scott@stud.man.ac.uk (Ian Scott) Date: Thu, 17 Jan 2002 11:15:34 -0000 Subject: [Cmake] .h files no longer get inserted in dsp files Message-ID: <000001c19f48$494b0700$22ea5882@ian> Hi. I have been lax in updating keeping my version of CMake up to date. Having gone from 0.97 to 1.3 at the last cvs up, I have noticed that cmake now ignores the .h files I specify when building dsp files. For example in the CMakeLists.txt file below, the .h files specified appeared in the dsp files and so got many of the nice features provided by MS DevStudio to work (word completion, parameter and member prompting, extra info during debug, etc.) With the new version of CMake however, the .h files don't appear in the dsp files. Is there a switch somewhere I can use to re-enable this? I can't find any relevant info in the PDF manual. Many thanks, Ian. # my_lib/cmakelists.txt ADD_LIBRARY(clsfy1 clsfy1_sources) SOURCE_FILES(clsfy1_sources my_lib_binary_p.cxx my_lib_binary_p_builder.cxx my_lib_c_builder.cxx my_lib_p.cxx my_lib_p_builder.cxx ) IF (WIN32) IF (NOT CYGWIN) SOURCE_FILES(my_lib_sources my_lib_binary_p.h my_lib_binary_p_builder.h my_lib_c.h my_lib_p.h my_lib_p_builder.h ) ENDIF (NOT CYGWIN) ENDIF(WIN32) AUX_SOURCE_DIRECTORY(Templates my_lib_sources) SUBDIRS(sv) IF( BUILD_TESTING) SUBDIRS(tests) ENDIF( BUILD_TESTING) From geoff@robots.ox.ac.uk Thu Jan 17 11:31:50 2002 From: geoff@robots.ox.ac.uk (Geoffrey Cross) Date: Thu, 17 Jan 2002 11:31:50 -0000 Subject: [Cmake] Line length in dsps Message-ID: <000401c19f4a$8f634b10$bb0c14ac@smirnov> I've got a vague feeling that I reported this issue and fixed it in some version of Cmake a long time ago, but it seems to have reappeared: Msdev version 6 can not handle dsps with lines longer than x characters (not exactly sure how big the limit is, but it is finite). When this occurs, the lines just get truncated randomly. Lines such as ADD LINK32 are typically rather long, but they can be spread over a number of lines with little performance loss when loading the dsps into msdev. Unless there is some other fix that I don't know about, PLEASE can someone put my patch back in to Cmake? Geoff. From bill.hoffman@kitware.com Thu Jan 17 12:39:38 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Thu, 17 Jan 2002 07:39:38 -0500 Subject: [Cmake] .h files no longer get inserted in dsp files In-Reply-To: <000001c19f48$494b0700$22ea5882@ian> Message-ID: <5.0.2.1.0.20020117073916.03db9598@pop.nycap.rr.com> This was not intentional, and must have slipped in somehow.... -Bill At 11:15 AM 1/17/2002 +0000, Ian Scott wrote: >Hi. > >I have been lax in updating keeping my version of CMake up to date. Having >gone from 0.97 to 1.3 at the last cvs up, I have noticed that cmake now >ignores the .h files I specify when building dsp files. > >For example in the CMakeLists.txt file below, the .h files specified >appeared in the dsp files and so got many of the nice features provided by >MS DevStudio to work (word completion, parameter and member prompting, extra >info during debug, etc.) >With the new version of CMake however, the .h files don't appear in the dsp >files. > >Is there a switch somewhere I can use to re-enable this? I can't find any >relevant info in the PDF manual. > >Many thanks, >Ian. > > ># my_lib/cmakelists.txt > >ADD_LIBRARY(clsfy1 clsfy1_sources) > >SOURCE_FILES(clsfy1_sources >my_lib_binary_p.cxx >my_lib_binary_p_builder.cxx >my_lib_c_builder.cxx >my_lib_p.cxx >my_lib_p_builder.cxx >) > > >IF (WIN32) > IF (NOT CYGWIN) > SOURCE_FILES(my_lib_sources > my_lib_binary_p.h > my_lib_binary_p_builder.h > my_lib_c.h > my_lib_p.h > my_lib_p_builder.h > ) > ENDIF (NOT CYGWIN) >ENDIF(WIN32) > > >AUX_SOURCE_DIRECTORY(Templates my_lib_sources) > >SUBDIRS(sv) > >IF( BUILD_TESTING) > SUBDIRS(tests) >ENDIF( BUILD_TESTING) > >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From bill.hoffman@kitware.com Thu Jan 17 12:53:56 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Thu, 17 Jan 2002 07:53:56 -0500 Subject: [Cmake] Line length in dsps In-Reply-To: <000401c19f4a$8f634b10$bb0c14ac@smirnov> Message-ID: <5.0.2.1.0.20020117074509.03d5a150@pop.nycap.rr.com> When does this happen? Your patch was this stuff: CM_MULTILINE_DEBUG_LIBRARIES CM_MULTILINE_LIBRARIES And, it is still there. I almost removed it, because if you use the multi-line format for dsp files, they can not be converted by the new .NET stuff, but I left it in there. For example, from a vtk executable dsp file: # ADD LINK32 /LIBPATH:"C:/Hoffman/vtknew-vc/bin/$(INTDIR)" /LIBPATH:"C:/Hoffma /vtknew-vc/bin/" # ADD LINK32 /LIBPATH:"C:/Hoffman/vtknew-vc/bin/$(INTDIR)" /LIBPATH:"C:/Hoffma /vtknew-vc/bin/" # ADD LINK32 vtkCommon.lib # ADD LINK32 vtkFiltering.lib # ADD LINK32 vtkGraphics.lib # ADD LINK32 vtkRendering.lib # ADD LINK32 opengl32.lib # ADD LINK32 vtkImaging.lib # ADD LINK32 vtkGraphics.lib # ADD LINK32 vtkIO.lib # ADD LINK32 vtkFiltering.lib # ADD LINK32 vtkCommon.lib # ADD LINK32 vtkpng.lib # ADD LINK32 vtkzlib.lib # ADD LINK32 vtkjpeg.lib # ADD LINK32 /STACK:10000000 At 11:31 AM 1/17/2002 +0000, Geoffrey Cross wrote: >I've got a vague feeling that I reported this issue and fixed it in some >version of Cmake a long time ago, but it seems to have reappeared: > >Msdev version 6 can not handle dsps with lines longer than x characters >(not exactly sure how big the limit is, but it is finite). When this >occurs, the lines just get truncated randomly. Lines such as ADD LINK32 >are typically rather long, but they can be spread over a number of lines >with little performance loss when loading the dsps into msdev. > >Unless there is some other fix that I don't know about, PLEASE can >someone put my patch back in to Cmake? > >Geoff. > >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From bill.hoffman@kitware.com Thu Jan 17 13:03:19 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Thu, 17 Jan 2002 08:03:19 -0500 Subject: [Cmake] Default output name for DLL In-Reply-To: <000201c19f47$e23a98f0$bb0c14ac@smirnov> Message-ID: <5.0.2.1.0.20020117075825.03cce4b0@pop.nycap.rr.com> I am not sure what is going on here... We use ADD_LIBRARY(something SHARED something_sources) in many places including the test case for cmake, and it has never generated a .exe file. (the tests would fail.) Perhaps you could run with an older version of cmake and the newer one, and do a diff on the dsp files. -Bill At 11:12 AM 1/17/2002 +0000, Geoffrey Cross wrote: >I just did a cvs update, and have now got a whole range of little >problems, the most puzzling being: > >I am building a bunch of dlls, which worked just fine under my previous >cmake installation (dating back to around the beginning of December). >The relevant line in my CMakeLists is: > >ADD_LIBRARY(something SHARED something_sources) > >In order to get the correct entry point, something_sources also needed >to include a .def file containing just the line: > >EXPORTS entry_point_function_name > >However, for some unknown reason, this no longer works and I get the >standard LNK1561 (entry point not defined) error. Finally, I found that >the .def file now needs to include the library name: > >LIBRARY something >EXPORTS entry_point_function_name > >That's solved, but I'm confused as to why this is necessary now, but >previously it wasn't (it also makes things slightly less pretty, as I >used to include the same .def file to generate a whole range of DLLS all >with the same entry point). > >More annoying, however, is that for some reason the DLL generated now >has a .exe extension! If I rename it to *.dll, everything works just >fine, but why!???! > >Geoff. > >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From geoff@robots.ox.ac.uk Thu Jan 17 13:17:32 2002 From: geoff@robots.ox.ac.uk (Geoffrey Cross) Date: Thu, 17 Jan 2002 13:17:32 -0000 Subject: [Cmake] Line length in dsps In-Reply-To: <5.0.2.1.0.20020117074509.03d5a150@pop.nycap.rr.com> Message-ID: <000001c19f59$53d358b0$bb0c14ac@smirnov> I see: it is only used in the EXE template and not the DLL template. I know it's a hack, and I know it's not very nice, but basically if you remove it Cmake will generate DSPs which are not read correctly by msdev 6 (not very useful, as that is the only reason to generate DSPs :). G. > -----Original Message----- > From: Bill Hoffman [mailto:bill.hoffman@kitware.com] > Sent: Thursday, January 17, 2002 12:54 PM > To: Geoffrey Cross; cmake@public.kitware.com > Subject: Re: [Cmake] Line length in dsps > > > When does this happen? > > Your patch was this stuff: > > CM_MULTILINE_DEBUG_LIBRARIES > CM_MULTILINE_LIBRARIES > > And, it is still there. I almost removed it, because if you > use the multi-line format > for dsp files, they can not be converted by the new .NET > stuff, but I left it in there. > > > For example, from a vtk executable dsp file: > > # ADD LINK32 /LIBPATH:"C:/Hoffman/vtknew-vc/bin/$(INTDIR)" > /LIBPATH:"C:/Hoffma /vtknew-vc/bin/" # ADD LINK32 > /LIBPATH:"C:/Hoffman/vtknew-vc/bin/$(INTDIR)" > /LIBPATH:"C:/Hoffma /vtknew-vc/bin/" # ADD LINK32 > vtkCommon.lib # ADD LINK32 vtkFiltering.lib # ADD LINK32 > vtkGraphics.lib # ADD LINK32 vtkRendering.lib # ADD LINK32 > opengl32.lib # ADD LINK32 vtkImaging.lib # ADD LINK32 > vtkGraphics.lib # ADD LINK32 vtkIO.lib # ADD LINK32 > vtkFiltering.lib # ADD LINK32 vtkCommon.lib # ADD LINK32 > vtkpng.lib # ADD LINK32 vtkzlib.lib # ADD LINK32 vtkjpeg.lib > # ADD LINK32 /STACK:10000000 > > > > At 11:31 AM 1/17/2002 +0000, Geoffrey Cross wrote: > > >I've got a vague feeling that I reported this issue and fixed it in > >some version of Cmake a long time ago, but it seems to have > reappeared: > > > >Msdev version 6 can not handle dsps with lines longer than x > characters > >(not exactly sure how big the limit is, but it is finite). > When this > >occurs, the lines just get truncated randomly. Lines such as ADD > >LINK32 are typically rather long, but they can be spread > over a number > >of lines with little performance loss when loading the dsps > into msdev. > > > >Unless there is some other fix that I don't know about, PLEASE can > >someone put my patch back in to Cmake? > > > >Geoff. > > > >_______________________________________________ > >Cmake mailing list > >Cmake@public.kitware.com > >http://public.kitware.com/mailman/listinfo/cmake > > From bill.hoffman@kitware.com Thu Jan 17 13:34:39 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Thu, 17 Jan 2002 08:34:39 -0500 Subject: [Cmake] Line length in dsps In-Reply-To: <000001c19f59$53d358b0$bb0c14ac@smirnov> References: <5.0.2.1.0.20020117074509.03d5a150@pop.nycap.rr.com> Message-ID: <5.0.2.1.0.20020117083332.03d49d68@pop.nycap.rr.com> I have no plans to remove it, but this did not change in cmake. Why are you only now having the problem? -bill At 01:17 PM 1/17/2002 +0000, Geoffrey Cross wrote: >I see: it is only used in the EXE template and not the DLL template. > >I know it's a hack, and I know it's not very nice, but basically if you >remove it Cmake will generate DSPs which are not read correctly by msdev >6 (not very useful, as that is the only reason to generate DSPs :). > >G. > > > >> -----Original Message----- >> From: Bill Hoffman [mailto:bill.hoffman@kitware.com] >> Sent: Thursday, January 17, 2002 12:54 PM >> To: Geoffrey Cross; cmake@public.kitware.com >> Subject: Re: [Cmake] Line length in dsps >> >> >> When does this happen? >> >> Your patch was this stuff: >> >> CM_MULTILINE_DEBUG_LIBRARIES >> CM_MULTILINE_LIBRARIES >> >> And, it is still there. I almost removed it, because if you >> use the multi-line format >> for dsp files, they can not be converted by the new .NET >> stuff, but I left it in there. >> >> >> For example, from a vtk executable dsp file: >> >> # ADD LINK32 /LIBPATH:"C:/Hoffman/vtknew-vc/bin/$(INTDIR)" >> /LIBPATH:"C:/Hoffma /vtknew-vc/bin/" # ADD LINK32 >> /LIBPATH:"C:/Hoffman/vtknew-vc/bin/$(INTDIR)" >> /LIBPATH:"C:/Hoffma /vtknew-vc/bin/" # ADD LINK32 >> vtkCommon.lib # ADD LINK32 vtkFiltering.lib # ADD LINK32 >> vtkGraphics.lib # ADD LINK32 vtkRendering.lib # ADD LINK32 >> opengl32.lib # ADD LINK32 vtkImaging.lib # ADD LINK32 >> vtkGraphics.lib # ADD LINK32 vtkIO.lib # ADD LINK32 >> vtkFiltering.lib # ADD LINK32 vtkCommon.lib # ADD LINK32 >> vtkpng.lib # ADD LINK32 vtkzlib.lib # ADD LINK32 vtkjpeg.lib >> # ADD LINK32 /STACK:10000000 >> >> >> >> At 11:31 AM 1/17/2002 +0000, Geoffrey Cross wrote: >> >> >I've got a vague feeling that I reported this issue and fixed it in >> >some version of Cmake a long time ago, but it seems to have >> reappeared: >> > >> >Msdev version 6 can not handle dsps with lines longer than x >> characters >> >(not exactly sure how big the limit is, but it is finite). >> When this >> >occurs, the lines just get truncated randomly. Lines such as ADD >> >LINK32 are typically rather long, but they can be spread >> over a number >> >of lines with little performance loss when loading the dsps >> into msdev. >> > >> >Unless there is some other fix that I don't know about, PLEASE can >> >someone put my patch back in to Cmake? >> > >> >Geoff. >> > >> >_______________________________________________ >> >Cmake mailing list >> >Cmake@public.kitware.com >> >http://public.kitware.com/mailman/listinfo/cmake >> >> > >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From billlist@nycap.rr.com Thu Jan 17 13:56:23 2002 From: billlist@nycap.rr.com (William A. Hoffman) Date: Thu, 17 Jan 2002 08:56:23 -0500 Subject: [Vxl-users] Fwd: [Cmake] CMake 1.2 Released In-Reply-To: <000101c19f49$cd342460$22ea5882@ian> References: <20020116141742.H83544@cs.rpi.edu> Message-ID: <5.0.2.1.0.20020117085049.03da2638@pop.nycap.rr.com> What version did this work with? I am looking at the code and I can not figure out how it ever worked..... As far back as version 1.1 of the dsp writer there has been this check on source files: if(!i->m_HeaderFileOnly) Perhaps it was a bug fix in the cmSourceFile object that caused the problem. In fact, that is what happened: revision 1.10 date: 2001/12/28 20:54:05; author: perera; state: Exp; lines: +8 -4 ENH: Classify a file as source or header even when the extension is given explicitly. -Bill At 11:26 AM 1/17/2002 +0000, you wrote: >If you are using MS DevStudio, I would advise against updating CMake just >now. > >For some reason the headers files are not getting put in the dspfiles >causing most of the intellisense features (word completion, etc.) to stop >working. > >I'll look into this, and try to get it fixed. > >Ian. > >> -----Original Message----- >> From: Amitha Perera [mailto:perera@cs.rpi.edu] >> Sent: Wednesday, January 16, 2002 7:18 PM >> To: vxl-users@lists.sourceforge.net >> Subject: [Vxl-users] Fwd: [Cmake] CMake 1.2 Released >> >> >> For those who are not following CMake CVS, you should probably update >> CMake. >> >> Amitha. >> >> ----- Forwarded message from Bill Hoffman >> ----- >> >> To: cmake@public.kitware.com >> From: Bill Hoffman >> Date: Wed, 16 Jan 2002 13:53:55 -0500 >> Subject: [Cmake] CMake 1.2 Released >> >> I would like to announce the release of CMake version 1.2. >> You can download binaries or source distributions from >> http://www.cmake.org/CMake/HTML/Download.html. You can also >> use the "Check for Updates" option from a previous >> windows binary installation. If you are using the cvs tree >> for ITK or VTK, then you should upgrade to CMake1.2. >> >> >> Summary of Changes: >> >> CMake now is much more selective about creating new dsp files >> significantly reducing the number of reloads done in Visual >> Studio. A new option to the IF command was added that tests >> if a file exists: IF (EXISTS filename) A number of fixes were >> added to the boreland and nmake build options. Borland now >> supports building shared and static libraries. A fix to the >> FIND_PATH command that could cause cmake to think the cache >> is always changing. Added CMAKE_EXTRA_LINK_FLAGS so that >> flags can be passed specifically to the linker. Enhancements >> to many modules and templates. Borland dll builds work. AIX >> shared libraries work with gcc. UNIX dependances are kept up-to-date. >> >> >> -Bill Hoffman >> >> >> ----- End forwarded message ----- >> >> _______________________________________________ >> Vxl-users mailing list >> Vxl-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/vxl-users >> > > >_______________________________________________ >Vxl-users mailing list >Vxl-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/vxl-users From brad.king@kitware.com Thu Jan 17 16:00:26 2002 From: brad.king@kitware.com (Brad King) Date: Thu, 17 Jan 2002 11:00:26 -0500 (EST) Subject: [Cmake] can't build on aix In-Reply-To: <3C463469.F4831B4F@schrodinger.com> Message-ID: Herc, Thanks for your report. > I just downloaded cmake and tried to build on aix 4.3.3 with the visual > age 5.0 c++ compiler. But it fails to build. I set CXX=/usr/bin/xlC. > > Is this code ANSI C++ compliant (not sure this is the issue but we have > had this issue with other stuff recently)? [snip] > "cmUnixMakefileGenerator.h", line 111.50: 1540-0040 (S) The text "&" is > unexpected. "cmMakeDepend" may be undeclared or ambiguous. > make: The error code from the last command is 1. The code is intended to be standard compliant, with various work-arounds to support non-compliant compilers. Your problem is a bug in the code, though, and it just happened that none of the compilers we use caught it. I just committed a fix to CVS. If you are using the release version, try adding the line class cmMakeDepend; below the lines class cmFunctionBlocker; class cmCommand; class cmMakefileGenerator; in CMake/Source/cmMakefile.h Please let us know if it builds okay after that. I don't believe we have ever tried using your compiler before. Thanks, -Brad From herc@schrodinger.com Thu Jan 17 18:25:56 2002 From: herc@schrodinger.com (Silverstein) Date: Thu, 17 Jan 2002 10:25:56 -0800 Subject: [Cmake] can't build on aix References: Message-ID: <3C471734.4EA6C99A@schrodinger.com> Brad King wrote: > > Herc, > > Thanks for your report. > > > I just downloaded cmake and tried to build on aix 4.3.3 with the visual > > age 5.0 c++ compiler. But it fails to build. I set CXX=/usr/bin/xlC. > > > > Is this code ANSI C++ compliant (not sure this is the issue but we have > > had this issue with other stuff recently)? > [snip] > > "cmUnixMakefileGenerator.h", line 111.50: 1540-0040 (S) The text "&" is > > unexpected. "cmMakeDepend" may be undeclared or ambiguous. > > make: The error code from the last command is 1. > > The code is intended to be standard compliant, with various work-arounds > to support non-compliant compilers. Your problem is a bug in the code, > though, and it just happened that none of the compilers we use caught it. > I just committed a fix to CVS. If you are using the release version, try > adding the line > > class cmMakeDepend; > > below the lines > > class cmFunctionBlocker; > class cmCommand; > class cmMakefileGenerator; > > in CMake/Source/cmMakefile.h > > Please let us know if it builds okay after that. I don't believe we have > ever tried using your compiler before. > > Thanks, > -Brad Thanks for the speedy reply. Now it gets farther, but not all the way. /usr/bin/xlC -DCMAKE_ROOT_DIR='"/home/herc/surf/CMake-1-2"' -g -DCMAKE_HAS_AUTOCONF -I/home/herc/surf/CMake-1-2/Source -c cmCableClassSet.cxx -o cmCableClassSet.o "cmCableClassSet.cxx", line 226.30: 1540-0300 (S) The "private" member "class ElementCombinationGenerator::Portion" cannot be accessed. make: 1254-004 The error code from the last command is 1. The declaration in the header shows the inheritance as being public, but for some reason it looks like the StringPortion class sees Portion as private. I tried making StringPortion and ElementCombinationGenerator friends of Portion, but no luck... Herc From bill.hoffman@kitware.com Thu Jan 17 19:01:45 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Thu, 17 Jan 2002 14:01:45 -0500 Subject: [Cmake] can't build on aix In-Reply-To: <3C471734.4EA6C99A@schrodinger.com> References: Message-ID: <5.0.2.1.0.20020117140002.03df72f8@pop.nycap.rr.com> Could you do a make -k in the build? That way we can see more of the errors up-front. For this one, try changing the private: to public: cmCableClassSet.cxx : line 156 class ElementCombinationGenerator { public: ElementCombinationGenerator(const char* in_element, cmMakefile* in_makefile, cmCableClassSet* out_set): m_Makefile(in_makefile), m_OutputSet(out_set) { this->ParseInputElement(in_element); } ~ElementCombinationGenerator(); void Generate(); private: ///*** change this to public: At 10:25 AM 1/17/2002 -0800, Silverstein wrote: >Brad King wrote: >> >> Herc, >> >> Thanks for your report. >> >> > I just downloaded cmake and tried to build on aix 4.3.3 with the visual >> > age 5.0 c++ compiler. But it fails to build. I set CXX=/usr/bin/xlC. >> > >> > Is this code ANSI C++ compliant (not sure this is the issue but we have >> > had this issue with other stuff recently)? >> [snip] >> > "cmUnixMakefileGenerator.h", line 111.50: 1540-0040 (S) The text "&" is >> > unexpected. "cmMakeDepend" may be undeclared or ambiguous. >> > make: The error code from the last command is 1. >> >> The code is intended to be standard compliant, with various work-arounds >> to support non-compliant compilers. Your problem is a bug in the code, >> though, and it just happened that none of the compilers we use caught it. >> I just committed a fix to CVS. If you are using the release version, try >> adding the line >> >> class cmMakeDepend; >> >> below the lines >> >> class cmFunctionBlocker; >> class cmCommand; >> class cmMakefileGenerator; >> >> in CMake/Source/cmMakefile.h >> >> Please let us know if it builds okay after that. I don't believe we have >> ever tried using your compiler before. >> >> Thanks, >> -Brad > >Thanks for the speedy reply. Now it gets farther, but not all the way. > > /usr/bin/xlC -DCMAKE_ROOT_DIR='"/home/herc/surf/CMake-1-2"' -g >-DCMAKE_HAS_AUTOCONF -I/home/herc/surf/CMake-1-2/Source -c >cmCableClassSet.cxx -o cmCableClassSet.o >"cmCableClassSet.cxx", line 226.30: 1540-0300 (S) The "private" member >"class ElementCombinationGenerator::Portion" cannot be accessed. >make: 1254-004 The error code from the last command is 1. > >The declaration in the header shows the inheritance as being public, but >for some reason it looks like the StringPortion class sees Portion as >private. I tried making StringPortion and ElementCombinationGenerator >friends of Portion, but no luck... > >Herc >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From Andy.Cedilnik@kitware.com Thu Jan 17 19:17:45 2002 From: Andy.Cedilnik@kitware.com (Andy Cedilnik) Date: Thu, 17 Jan 2002 14:17:45 -0500 Subject: [Cmake] Added feature to source files Message-ID: <5.1.0.14.0.20020117141231.00a8ed70@pop.nycap.rr.com> Hello! I just added option of adding to source list files that will be generated during the build process. The syntax of SOURCE_FILES is compatible with the old syntax but it has keyword GENERATED to specify files that will be generated. For example: SOURCE_FILES ( Project_SRCS File1 File2 ... GENERATED GFile1 GFile2 ... ) So, files File1, File2 and so on, have to exist during CMake stage. Files GFile1, GFile2, and so on, do not have to exist. So, using ADD_CUSTOM_COMMAND and GENERATED in SOURCE_FILES, you could do something like custom wrapping. Hope you like it. Andy Cedilnik From sebastien.barre@kitware.com Thu Jan 17 20:53:01 2002 From: sebastien.barre@kitware.com (Sebastien BARRE) Date: Thu, 17 Jan 2002 15:53:01 -0500 Subject: [Cmake] Added feature to source files In-Reply-To: <5.1.0.14.0.20020117141231.00a8ed70@pop.nycap.rr.com> Message-ID: <5.1.0.14.2.20020117145806.02f97850@pop.fr.clara.net> At 1/17/2002 02:17 PM, Andy Cedilnik wrote: >So, using ADD_CUSTOM_COMMAND and GENERATED in SOURCE_FILES, >you could do something like custom wrapping. CMake now covers and tests the ADD_CUSTOM_COMMAND The test is in: CMake\Tests\Complex\Library\CMakeLists.txt which indeed showed today that the Unix makefile generator was not handling some dependencies properly. It has been fixed so that the utilities dependencies are written too, i.e. ADD_DEPENDENCIES now work for Unix/Nmake/Borland. CMake now also covers and tests the ADD_DEPENDENCIES commands (in the same test, see above). -- Sebastien Barre From wheeler@crd.ge.com Fri Jan 18 00:35:00 2002 From: wheeler@crd.ge.com (Wheeler, Fred (CRD)) Date: Thu, 17 Jan 2002 19:35:00 -0500 Subject: [Cmake] cmake seems to crash because 0x0 is used in place of "" Message-ID: I'm getting cmake to core dump. I hope this report helps. My guess is that def is being set to 0 in cmIfCommand.cxx, but that should be interpreted as an empty string. I can fix the problem in Solaris with "export LD_PRELOAD=0@0.so.1" which puts an empty string \0 at memory location 0x0 to solve such problems. Below is some output from gdb. Fred Wheeler 0% gdb $SR_CMAKE core GNU gdb 5.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.7"... Core was generated by `/no_backup/wheeler/prj/sr/cmake_usr/bin/cmake /no_backup/wheeler/prj/sr/vxl_src'. Program terminated with signal 11, Segmentation fault. Reading symbols from /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libstdc++.so.3...done. Loaded symbols for /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libstdc++.so.3 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libgcc_s.so.1...done. Loaded symbols for /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libgcc_s.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1... done. Loaded symbols for /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1 #0 0xff1ce5b0 in ?? () (gdb) where #0 0xff1ce5b0 in ?? () #1 0x0005dcb8 in cmIfCommand::InitialPass(std::vector > const&) (this=0x1aa578, args=@0x19290c) at /no_backup/wheeler/prj/sr/cmake_src/Source/cmIfCommand.cxx:173 #2 0x00038a64 in cmMakefile::ExecuteCommand(std::string&, std::vector > const&) (this=0x19b948, name=@0x192908, arguments=@0x19290c) at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:238 #3 0x00038e94 in cmMakefile::ReadListFile(char const*, char const*) ( this=0x19b948, filename=0x175e1c "/no_backup/wheeler/prj/sr/vxl_src/CMakeLists.txt", external=0x19290c "") at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:350 #4 0x0005e4a0 in cmIncludeCommand::InitialPass(std::vector > const&) (this=0x1aa548, argsIn=@0xffbee2cc) at /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/gcc-lib/../../../include/g++-v3/bits/basic_string.h: 208 #5 0x00038a64 in cmMakefile::ExecuteCommand(std::string&, std::vector > const&) (this=0x19b948, name=@0x1a77b0, arguments=@0x1a77b4) at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:238 #6 0x00038e94 in cmMakefile::ReadListFile(char const*, char const*) ( this=0x19b948, filename=0x175dcc "/no_backup/wheeler/prj/sr/vxl_src/vxl/vul/io/tests/CMakeLists.txt", external=0x1a77b4 "") ---Type to continue, or q to quit--- at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:350 #7 0x0003f480 in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vector >&) (this=0x19a538, makefiles=@0xffbee788) at /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/gcc-lib/../../../include/g++-v3/bits/basic_string.h: 714 #8 0x0003f48c in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vector >&) (this=0x199610, makefiles=@0xffbee788) at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:1137 #9 0x0003f48c in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vector >&) (this=0x1885d8, makefiles=@0xffbee788) at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:1137 #10 0x0003f48c in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vector >&) (this=0xffbeea20, makefiles=@0xffbee788) at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:1137 #11 0x00092914 in cmUnixMakefileGenerator::RecursiveGenerateCacheOnly() ( this=0x130238) at /no_backup/wheeler/prj/sr/cmake_src/Source/cmUnixMakefileGenerator.cxx:1333 #12 0x0008733c in cmUnixMakefileGenerator::GenerateMakefile() (this=0x130238) at /no_backup/wheeler/prj/sr/cmake_src/Source/cmUnixMakefileGenerator.cxx:115 #13 0x0003972c in cmMakefile::GenerateMakefile() (this=0xffbeea20) at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:437 #14 0x00034060 in cmake::Generate(std::vector > const&, bool) (this=0xffbeebb8, args=@0xffbeebc0, buildMakefiles=true) ---Type to continue, or q to quit--- at /no_backup/wheeler/prj/sr/cmake_src/Source/cmake.cxx:424 #15 0x00030f50 in main (ac=2, av=0xffbeec44) at /no_backup/wheeler/prj/sr/cmake_src/Source/cmakemain.cxx:23 (gdb) up #1 0x0005dcb8 in cmIfCommand::InitialPass(std::vector > const&) (this=0x1aa578, args=@0x19290c) at /no_backup/wheeler/prj/sr/cmake_src/Source/cmIfCommand.cxx:173 173 if (!regEntry.find(def)) (gdb) print def $1 = 0x0 -- Fred Wheeler, GE CRD, KWC-303 Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) From herc@schrodinger.com Fri Jan 18 01:19:24 2002 From: herc@schrodinger.com (Silverstein) Date: Thu, 17 Jan 2002 17:19:24 -0800 Subject: [Cmake] can't build on aix References: <5.0.2.1.0.20020117140002.03df72f8@pop.nycap.rr.com> Message-ID: <3C47781C.BA18CF4F@schrodinger.com> Bill Hoffman wrote: > > Could you do a make -k in the build? That way we can see more of the errors up-front. > For this one, try changing the private: to public: > OK, that looks like it worked and I have a binary. Thanks Herc > cmCableClassSet.cxx : line 156 > class ElementCombinationGenerator > { > public: > ElementCombinationGenerator(const char* in_element, cmMakefile* in_makefile, > cmCableClassSet* out_set): > m_Makefile(in_makefile), m_OutputSet(out_set) > { > this->ParseInputElement(in_element); > } > ~ElementCombinationGenerator(); > > void Generate(); > > private: ///*** change this to public: > > At 10:25 AM 1/17/2002 -0800, Silverstein wrote: > >Brad King wrote: > >> > >> Herc, > >> > >> Thanks for your report. > >> > >> > I just downloaded cmake and tried to build on aix 4.3.3 with the visual > >> > age 5.0 c++ compiler. But it fails to build. I set CXX=/usr/bin/xlC. > >> > > >> > Is this code ANSI C++ compliant (not sure this is the issue but we have > >> > had this issue with other stuff recently)? > >> [snip] > >> > "cmUnixMakefileGenerator.h", line 111.50: 1540-0040 (S) The text "&" is > >> > unexpected. "cmMakeDepend" may be undeclared or ambiguous. > >> > make: The error code from the last command is 1. > >> > >> The code is intended to be standard compliant, with various work-arounds > >> to support non-compliant compilers. Your problem is a bug in the code, > >> though, and it just happened that none of the compilers we use caught it. > >> I just committed a fix to CVS. If you are using the release version, try > >> adding the line > >> > >> class cmMakeDepend; > >> > >> below the lines > >> > >> class cmFunctionBlocker; > >> class cmCommand; > >> class cmMakefileGenerator; > >> > >> in CMake/Source/cmMakefile.h > >> > >> Please let us know if it builds okay after that. I don't believe we have > >> ever tried using your compiler before. > >> > >> Thanks, > >> -Brad > > > >Thanks for the speedy reply. Now it gets farther, but not all the way. > > > > /usr/bin/xlC -DCMAKE_ROOT_DIR='"/home/herc/surf/CMake-1-2"' -g > >-DCMAKE_HAS_AUTOCONF -I/home/herc/surf/CMake-1-2/Source -c > >cmCableClassSet.cxx -o cmCableClassSet.o > >"cmCableClassSet.cxx", line 226.30: 1540-0300 (S) The "private" member > >"class ElementCombinationGenerator::Portion" cannot be accessed. > >make: 1254-004 The error code from the last command is 1. > > > >The declaration in the header shows the inheritance as being public, but > >for some reason it looks like the StringPortion class sees Portion as > >private. I tried making StringPortion and ElementCombinationGenerator > >friends of Portion, but no luck... > > > >Herc > >_______________________________________________ > >Cmake mailing list > >Cmake@public.kitware.com > >http://public.kitware.com/mailman/listinfo/cmake From bill.hoffman@kitware.com Fri Jan 18 11:55:43 2002 From: bill.hoffman@kitware.com (William A. Hoffman) Date: Fri, 18 Jan 2002 06:55:43 -0500 Subject: [Cmake] Re: library dependency information In-Reply-To: <20020117164730.J61748@cs.rpi.edu> References: <5.0.2.1.0.20020117163730.02d3d680@pop.nycap.rr.com> <20020117120716.F61748@cs.rpi.edu> <20020117114007.E61748@cs.rpi.edu> <5.0.2.1.0.20020117114733.03dfe7a0@pop.nycap.rr.com> <20020117120716.F61748@cs.rpi.edu> <20020117143228.H61748@cs.rpi.edu> <5.0.2.1.0.20020117163730.02d3d680@pop.nycap.rr.com> Message-ID: <5.0.2.1.0.20020118064757.02d33130@pop.nycap.rr.com> So, to summarize: 1. You will add an option that removes duplicates just like the -L options are currently removed. 2. For static builds you will use the libraries that have been linked to libraries to get all the needed libraries for an exectuable: So if you have: libA -> libB Then you have an executable foo.exe that has a TARGET_LINK_LIBRARY(foo A) you will know to add the -lB in the right order. If projects are building on Windows all libraries will have the list of libraries that they link against, so most projects will have this information. You will have to make a cache entry to store the information. Something like: A_LIBRARY_LINKS:INTERNAL:B There is already some stuff like that going on in the cache, look at your cache to see. Also, I like the idea of moving this into the generator parent class. We could add a method there to collapse the library path and library link options. The code is duplicated in the two generators now. -Bill At 04:47 PM 1/17/2002 -0500, Amitha Perera wrote: > > I don't see how this will help to compress the path. You could add a > > variable that stops the > > library duplication that is done on unix, but other than that, I don't see > > what you are going to > > do that is different than what is being done. > >In the general case, you are right, it will do nothing. There are two >additional pieces that can be used to do more: > >1. If the libraries are known to have a tree-like dependency > structure, and the libraries are known to be specified in the correct > order, you can remove duplicates: > -la -lb -la => -lb -la > >2. If the CMakeLists.txt has full dependency information (that the > developers have explicitly added), then a lot of reduction can be > done. > ADD_LIBRARY( z ) > ADD_LIBRARY( a ) > ADD_LIBRARY( c ) > TARGET_LINK_LIBRARIES( c a ) > ADD_LIBRARY( b ) > TARGET_LINK_LIBRARIES( b a ) > TARGET_LINK_LIBRARIES( a z ) > ADD_EXECUTABLE( e ) > TARGET_LINK_LIBRARIES( e c b ) > The link line for e can automatically be determined as > -lc -lb -la -lz or -lb -lc -la -lz > >Part 2 requires the explicit entry of dependencies, which takes effort >and is probably not in place for many projects. However, I strongly >believe it is not in place because no (Unix?) tools really have a >place to use that information, or use it effectively. CMake is a tool >that can really put that information to use. In particular, if this >information is in place, then a parallel build dependency would go >something like: > e <--- c <--- a <---- z > \-- b <--/ >which is the most parallelism you can expect, and still be consistent >with the serial build. > >Yes, I admit most projects may not use it, but I like to think that if >it were available, and well documented, more people would adopt it. > >For vxl in particular, the CMakeListsLink.txt is a hack to document >the immediate dependencies for each library, so that the full >dependencies can be automatically generated. This would give a better >way of doing that. > >Amitha. From bill.hoffman@kitware.com Fri Jan 18 12:40:19 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Fri, 18 Jan 2002 07:40:19 -0500 Subject: [Cmake] cmake seems to crash because 0x0 is used in place of "" In-Reply-To: Message-ID: <5.0.2.1.0.20020118074004.03de5f50@pop.nycap.rr.com> Thanks for the report, I think I have checked in a fix. At 07:35 PM 1/17/2002 -0500, Wheeler, Fred (CRD) wrote: >I'm getting cmake to core dump. I hope this report helps. My guess >is that def is being set to 0 in cmIfCommand.cxx, but that should be >interpreted as an empty string. I can fix the problem in Solaris with >"export LD_PRELOAD=0@0.so.1" which puts an empty string \0 at memory >location 0x0 to solve such problems. > >Below is some output from gdb. > >Fred Wheeler > >0% gdb $SR_CMAKE core >GNU gdb 5.1 >Copyright 2001 Free Software Foundation, Inc. >GDB is free software, covered by the GNU General Public License, and you are >welcome to change it and/or distribute copies of it under certain conditions. >Type "show copying" to see the conditions. >There is absolutely no warranty for GDB. Type "show warranty" for details. >This GDB was configured as "sparc-sun-solaris2.7"... >Core was generated by `/no_backup/wheeler/prj/sr/cmake_usr/bin/cmake >/no_backup/wheeler/prj/sr/vxl_src'. >Program terminated with signal 11, Segmentation fault. >Reading symbols from /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libstdc++.so.3...done. >Loaded symbols for /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libstdc++.so.3 >Reading symbols from /usr/lib/libm.so.1...done. >Loaded symbols for /usr/lib/libm.so.1 >Reading symbols from /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libgcc_s.so.1...done. >Loaded symbols for /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libgcc_s.so.1 >Reading symbols from /usr/lib/libc.so.1...done. >Loaded symbols for /usr/lib/libc.so.1 >Reading symbols from /usr/lib/libdl.so.1...done. >Loaded symbols for /usr/lib/libdl.so.1 >Reading symbols from /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1... >done. >Loaded symbols for /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1 >#0 0xff1ce5b0 in ?? () >(gdb) where >#0 0xff1ce5b0 in ?? () >#1 0x0005dcb8 in cmIfCommand::InitialPass(std::vector > >const&) (this=0x1aa578, args=@0x19290c) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmIfCommand.cxx:173 >#2 0x00038a64 in cmMakefile::ExecuteCommand(std::string&, std::vectorstd::allocator > const&) (this=0x19b948, name=@0x192908, > arguments=@0x19290c) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:238 >#3 0x00038e94 in cmMakefile::ReadListFile(char const*, char const*) ( > this=0x19b948, > filename=0x175e1c "/no_backup/wheeler/prj/sr/vxl_src/CMakeLists.txt", > external=0x19290c "") > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:350 >#4 0x0005e4a0 in cmIncludeCommand::InitialPass(std::vector >> const&) (this=0x1aa548, argsIn=@0xffbee2cc) > at >/home/wheeler/usr/local/sparc-sun-solaris2.7/lib/gcc-lib/../../../include/g++-v3/bits/basic_string.h: >208 >#5 0x00038a64 in cmMakefile::ExecuteCommand(std::string&, std::vectorstd::allocator > const&) (this=0x19b948, name=@0x1a77b0, > arguments=@0x1a77b4) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:238 >#6 0x00038e94 in cmMakefile::ReadListFile(char const*, char const*) ( > this=0x19b948, > filename=0x175dcc "/no_backup/wheeler/prj/sr/vxl_src/vxl/vul/io/tests/CMakeLists.txt", >external=0x1a77b4 "") >---Type to continue, or q to quit--- > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:350 >#7 0x0003f480 in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vectorstd::allocator >&) (this=0x19a538, makefiles=@0xffbee788) > at >/home/wheeler/usr/local/sparc-sun-solaris2.7/lib/gcc-lib/../../../include/g++-v3/bits/basic_string.h: >714 >#8 0x0003f48c in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vectorstd::allocator >&) (this=0x199610, makefiles=@0xffbee788) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:1137 >#9 0x0003f48c in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vectorstd::allocator >&) (this=0x1885d8, makefiles=@0xffbee788) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:1137 >#10 0x0003f48c in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vectorstd::allocator >&) (this=0xffbeea20, makefiles=@0xffbee788) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:1137 >#11 0x00092914 in cmUnixMakefileGenerator::RecursiveGenerateCacheOnly() ( > this=0x130238) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmUnixMakefileGenerator.cxx:1333 >#12 0x0008733c in cmUnixMakefileGenerator::GenerateMakefile() (this=0x130238) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmUnixMakefileGenerator.cxx:115 >#13 0x0003972c in cmMakefile::GenerateMakefile() (this=0xffbeea20) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:437 >#14 0x00034060 in cmake::Generate(std::vector > const&, >bool) (this=0xffbeebb8, args=@0xffbeebc0, buildMakefiles=true) >---Type to continue, or q to quit--- > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmake.cxx:424 >#15 0x00030f50 in main (ac=2, av=0xffbeec44) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmakemain.cxx:23 >(gdb) up >#1 0x0005dcb8 in cmIfCommand::InitialPass(std::vector > >const&) (this=0x1aa578, args=@0x19290c) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmIfCommand.cxx:173 >173 if (!regEntry.find(def)) >(gdb) print def >$1 = 0x0 > > >-- >Fred Wheeler, GE CRD, KWC-303 >Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) >Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From wheeler@crd.ge.com Fri Jan 18 21:39:56 2002 From: wheeler@crd.ge.com (Wheeler, Fred (CRD)) Date: Fri, 18 Jan 2002 16:39:56 -0500 Subject: [Cmake] cmake seems to crash because 0x0 is used in place of "" Message-ID: Bill, Something checked in between "2002-01-14 4:00" and "2002-01-18 16:00" has fixed this problem. Thanks. FYI, the twm (tab window manager) shipped by Sun in several recent Solaris versions has had the same bug, also fixed by LD_PRELOAD=0@0.so.1. Fred Wheeler -- Fred Wheeler, GE CRD, KWC-303 Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) -----Original Message----- From: Bill Hoffman [mailto:bill.hoffman@kitware.com] Sent: Friday, January 18, 2002 7:40 AM To: Wheeler, Fred (CRD); 'cmake@public.kitware.com' Subject: Re: [Cmake] cmake seems to crash because 0x0 is used in place of "" Thanks for the report, I think I have checked in a fix. At 07:35 PM 1/17/2002 -0500, Wheeler, Fred (CRD) wrote: >I'm getting cmake to core dump. I hope this report helps. My guess >is that def is being set to 0 in cmIfCommand.cxx, but that should be >interpreted as an empty string. I can fix the problem in Solaris with >"export LD_PRELOAD=0@0.so.1" which puts an empty string \0 at memory >location 0x0 to solve such problems. > >Below is some output from gdb. > >Fred Wheeler > >0% gdb $SR_CMAKE core >GNU gdb 5.1 >Copyright 2001 Free Software Foundation, Inc. >GDB is free software, covered by the GNU General Public License, and you are >welcome to change it and/or distribute copies of it under certain conditions. >Type "show copying" to see the conditions. >There is absolutely no warranty for GDB. Type "show warranty" for details. >This GDB was configured as "sparc-sun-solaris2.7"... >Core was generated by `/no_backup/wheeler/prj/sr/cmake_usr/bin/cmake >/no_backup/wheeler/prj/sr/vxl_src'. >Program terminated with signal 11, Segmentation fault. >Reading symbols from /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libstdc++.so.3...done. >Loaded symbols for /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libstdc++.so.3 >Reading symbols from /usr/lib/libm.so.1...done. >Loaded symbols for /usr/lib/libm.so.1 >Reading symbols from /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libgcc_s.so.1...done. >Loaded symbols for /home/wheeler/usr/local/sparc-sun-solaris2.7/lib/libgcc_s.so.1 >Reading symbols from /usr/lib/libc.so.1...done. >Loaded symbols for /usr/lib/libc.so.1 >Reading symbols from /usr/lib/libdl.so.1...done. >Loaded symbols for /usr/lib/libdl.so.1 >Reading symbols from /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1... >done. >Loaded symbols for /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1 >#0 0xff1ce5b0 in ?? () >(gdb) where >#0 0xff1ce5b0 in ?? () >#1 0x0005dcb8 in cmIfCommand::InitialPass(std::vector > >const&) (this=0x1aa578, args=@0x19290c) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmIfCommand.cxx:173 >#2 0x00038a64 in cmMakefile::ExecuteCommand(std::string&, std::vectorstd::allocator > const&) (this=0x19b948, name=@0x192908, > arguments=@0x19290c) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:238 >#3 0x00038e94 in cmMakefile::ReadListFile(char const*, char const*) ( > this=0x19b948, > filename=0x175e1c "/no_backup/wheeler/prj/sr/vxl_src/CMakeLists.txt", > external=0x19290c "") > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:350 >#4 0x0005e4a0 in cmIncludeCommand::InitialPass(std::vector >> const&) (this=0x1aa548, argsIn=@0xffbee2cc) > at >/home/wheeler/usr/local/sparc-sun-solaris2.7/lib/gcc-lib/../../../include/g++-v3/bits/basic_string.h : >208 >#5 0x00038a64 in cmMakefile::ExecuteCommand(std::string&, std::vectorstd::allocator > const&) (this=0x19b948, name=@0x1a77b0, > arguments=@0x1a77b4) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:238 >#6 0x00038e94 in cmMakefile::ReadListFile(char const*, char const*) ( > this=0x19b948, > filename=0x175dcc "/no_backup/wheeler/prj/sr/vxl_src/vxl/vul/io/tests/CMakeLists.txt", >external=0x1a77b4 "") >---Type to continue, or q to quit--- > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:350 >#7 0x0003f480 in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vectorstd::allocator >&) (this=0x19a538, makefiles=@0xffbee788) > at >/home/wheeler/usr/local/sparc-sun-solaris2.7/lib/gcc-lib/../../../include/g++-v3/bits/basic_string.h : >714 >#8 0x0003f48c in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vectorstd::allocator >&) (this=0x199610, makefiles=@0xffbee788) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:1137 >#9 0x0003f48c in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vectorstd::allocator >&) (this=0x1885d8, makefiles=@0xffbee788) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:1137 >#10 0x0003f48c in cmMakefile::FindSubDirectoryCMakeListsFiles(std::vectorstd::allocator >&) (this=0xffbeea20, makefiles=@0xffbee788) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:1137 >#11 0x00092914 in cmUnixMakefileGenerator::RecursiveGenerateCacheOnly() ( > this=0x130238) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmUnixMakefileGenerator.cxx:1333 >#12 0x0008733c in cmUnixMakefileGenerator::GenerateMakefile() (this=0x130238) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmUnixMakefileGenerator.cxx:115 >#13 0x0003972c in cmMakefile::GenerateMakefile() (this=0xffbeea20) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmMakefile.cxx:437 >#14 0x00034060 in cmake::Generate(std::vector > const&, >bool) (this=0xffbeebb8, args=@0xffbeebc0, buildMakefiles=true) >---Type to continue, or q to quit--- > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmake.cxx:424 >#15 0x00030f50 in main (ac=2, av=0xffbeec44) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmakemain.cxx:23 >(gdb) up >#1 0x0005dcb8 in cmIfCommand::InitialPass(std::vector > >const&) (this=0x1aa578, args=@0x19290c) > at /no_backup/wheeler/prj/sr/cmake_src/Source/cmIfCommand.cxx:173 >173 if (!regEntry.find(def)) >(gdb) print def >$1 = 0x0 > > >-- >Fred Wheeler, GE CRD, KWC-303 >Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) >Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From lorensen@crd.ge.com Tue Jan 22 16:30:38 2002 From: lorensen@crd.ge.com (Lorensen, William E (CRD)) Date: Tue, 22 Jan 2002 11:30:38 -0500 Subject: [Cmake] Slowness of Cmake.pdf update Message-ID: Folks, Is there anything that we can do to speed up the CMake.pdf update? Bill From brad.king@kitware.com Tue Jan 22 17:15:03 2002 From: brad.king@kitware.com (Brad King) Date: Tue, 22 Jan 2002 12:15:03 -0500 (EST) Subject: [Cmake] Slowness of Cmake.pdf update In-Reply-To: Message-ID: > Is there anything that we can do to speed up the CMake.pdf update? Whenever it gets stuck for me, I just break it and use cvs -z3. It then goes nice and quickly. Even though the server uses -z3 by default, the client seems to need it to get around this bug. -Brad From bill.hoffman@kitware.com Tue Jan 22 17:38:20 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Tue, 22 Jan 2002 12:38:20 -0500 Subject: [Cmake] Slowness of Cmake.pdf update In-Reply-To: References: Message-ID: <5.0.2.1.0.20020122123648.03df7c48@pop.nycap.rr.com> I suppose the other option would be to move the pdf file to the CMakeWeb tree out of the CMake tree. We also now have tar balls on the ftp server of the most recent release. -Bill At 12:15 PM 1/22/2002 -0500, Brad King wrote: >> Is there anything that we can do to speed up the CMake.pdf update? >Whenever it gets stuck for me, I just break it and use cvs -z3. It then >goes nice and quickly. Even though the server uses -z3 by default, the >client seems to need it to get around this bug. > >-Brad > >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From lorensen@crd.ge.com Tue Jan 22 18:49:28 2002 From: lorensen@crd.ge.com (Lorensen, William E (CRD)) Date: Tue, 22 Jan 2002 13:49:28 -0500 Subject: [Cmake] SOURCE_FILES default extension Message-ID: How does cmake find the extension to use in the SOURCE_FILES statement? I just had an example that used VTK and ITK. My SOURCE_FILES line looked like this SOURCE_FILES(Distance_SRCS Distance Options ) The first time cmake generated the Makefile, it correctly guessed the extension as "cxx". I successfully built the program (called Distance). Then I edited the source file and did another gmake. cmake generated a new Makefile with the compile line using the executable name rather than the .cxx file. Seems that the second time, it found that the file listed in the SOURCE_FILES was there (the executable this time) and messed up my Makefile. If I remove the Distance file and rerun cmake, it generates the correct Makefile. To fix the problem, I changed my command to: SOURCE_FILES(Distance_SRCS Distance.cxx Options.cxx ) and all was fine. Seems that cmake should REQUIRE an extension on these source files. Bill From bill.hoffman@kitware.com Tue Jan 22 20:37:23 2002 From: bill.hoffman@kitware.com (Bill Hoffman) Date: Tue, 22 Jan 2002 15:37:23 -0500 Subject: [Cmake] SOURCE_FILES default extension In-Reply-To: Message-ID: <5.0.2.1.0.20020122153514.03e60eb0@pop.nycap.rr.com> Cmake looks for the file with no extension first, then tries cxx cpp, mm, h, etc. At one point I thought it would be better if you had to give the extension. However, at this point, it would be hard to change all the projects using cmake. I guess it could be a style for list files, that you should use the full file name, but I would not want to break/change existing projects. -Bill At 03:40 PM 1/22/2002 -0500, Brad King wrote: >---------- Forwarded message ---------- >Date: Tue, 22 Jan 2002 13:49:28 -0500 >From: "Lorensen, William E (CRD)" >To: cmake@public.kitware.com >Subject: [Cmake] SOURCE_FILES default extension > >How does cmake find the extension to use in the SOURCE_FILES statement? > >I just had an example that used VTK and ITK. My SOURCE_FILES line looked like this >SOURCE_FILES(Distance_SRCS >Distance >Options >) > >The first time cmake generated the Makefile, it correctly guessed the extension as "cxx". I >successfully built the program (called Distance). Then I edited the source file and did another >gmake. cmake generated a new Makefile with the compile line using the executable name rather than the >.cxx file. >Seems that the second time, it found that the file listed in the SOURCE_FILES was there (the >executable this time) and messed up my Makefile. If I remove the Distance file and rerun cmake, it >generates the correct Makefile. > >To fix the problem, I changed my command to: > >SOURCE_FILES(Distance_SRCS >Distance.cxx >Options.cxx >) > >and all was fine. > >Seems that cmake should REQUIRE an extension on these source files. > >Bill > > >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From geoff@robots.ox.ac.uk Thu Jan 24 09:43:13 2002 From: geoff@robots.ox.ac.uk (Geoffrey Cross) Date: Thu, 24 Jan 2002 09:43:13 -0000 Subject: [Cmake] SOURCE_FILES default extension In-Reply-To: <5.0.2.1.0.20020122153514.03e60eb0@pop.nycap.rr.com> Message-ID: <000e01c1a4bb$8bc46c70$bb0c14ac@smirnov> I agree with Bill L: I think it should be mandatory to put an extension on the file name. Can't we provide a script which will fix the cmakelists and give a warning for a short while before breaking projects? As with VXL, there are inevitably going to be times when you need to break things for the sake of sanity, and I think this is an example. Geoff. > -----Original Message----- > From: cmake-admin@public.kitware.com > [mailto:cmake-admin@public.kitware.com] On Behalf Of Bill Hoffman > Sent: Tuesday, January 22, 2002 8:37 PM > To: Lorensen, William E (CRD) > Cc: cmake@public.kitware.com > Subject: Re: [Cmake] SOURCE_FILES default extension > > > Cmake looks for the file with no extension first, then tries > cxx cpp, mm, h, etc. At one point I thought it would be > better if you had to give the extension. However, at this > point, it would be hard to change all the projects using > cmake. I guess it could be a style for list files, that you > should use the full file name, but I would not want to > break/change existing projects. > > -Bill > > > At 03:40 PM 1/22/2002 -0500, Brad King wrote: > > > >---------- Forwarded message ---------- > >Date: Tue, 22 Jan 2002 13:49:28 -0500 > >From: "Lorensen, William E (CRD)" > >To: cmake@public.kitware.com > >Subject: [Cmake] SOURCE_FILES default extension > > > >How does cmake find the extension to use in the SOURCE_FILES > statement? > > > >I just had an example that used VTK and ITK. My SOURCE_FILES line > >looked like this SOURCE_FILES(Distance_SRCS Distance > >Options > >) > > > >The first time cmake generated the Makefile, it correctly > guessed the > >extension as "cxx". I successfully built the program (called > Distance). > >Then I edited the source file and did another gmake. cmake > generated a > >new Makefile with the compile line using the executable name rather > >than the .cxx file. Seems that the second time, it found > that the file > >listed in the SOURCE_FILES was there (the executable this time) and > >messed up my Makefile. If I remove the Distance file and > rerun cmake, > >it generates the correct Makefile. > > > >To fix the problem, I changed my command to: > > > >SOURCE_FILES(Distance_SRCS > >Distance.cxx > >Options.cxx > >) > > > >and all was fine. > > > >Seems that cmake should REQUIRE an extension on these source files. > > > >Bill > > > > > >_______________________________________________ > >Cmake mailing list > >Cmake@public.kitware.com > >http://public.kitware.com/mailman/listinfo/cmake > > _______________________________________________ > Cmake mailing list > Cmake@public.kitware.com > http://public.kitware.com/mailman/listinfo/cma> ke > > From bill.hoffman@kitware.com Thu Jan 24 13:47:20 2002 From: bill.hoffman@kitware.com (William A. Hoffman) Date: Thu, 24 Jan 2002 08:47:20 -0500 Subject: [Cmake] SOURCE_FILES default extension In-Reply-To: <000e01c1a4bb$8bc46c70$bb0c14ac@smirnov> References: <5.0.2.1.0.20020122153514.03e60eb0@pop.nycap.rr.com> Message-ID: <5.0.2.1.0.20020124084348.02efc008@pop.nycap.rr.com> I think the best thing we can do at this point is to make it an undocumented feature. We change all the projects that are using it, change all the examples, and change the cmake documentation. If a new user finds out about it, then so what. I would like newer versions of cmake to still be able to build VTK 4.0 for at least 6 months to a year. We have already made the VTK 4.0 branch, and do not want to make a massive change like this on the branch. Soon we will be printing a 1000 CD's, and if someone happens to have a newer cmake, it should work. -Bill At 09:43 AM 1/24/2002 +0000, Geoffrey Cross wrote: >I agree with Bill L: I think it should be mandatory to put an extension >on the file name. Can't we provide a script which will fix the >cmakelists and give a warning for a short while before breaking >projects? As with VXL, there are inevitably going to be times when you >need to break things for the sake of sanity, and I think this is an >example. > >Geoff. > > > > -----Original Message----- > > From: cmake-admin@public.kitware.com > > [mailto:cmake-admin@public.kitware.com] On Behalf Of Bill Hoffman > > Sent: Tuesday, January 22, 2002 8:37 PM > > To: Lorensen, William E (CRD) > > Cc: cmake@public.kitware.com > > Subject: Re: [Cmake] SOURCE_FILES default extension > > > > > > Cmake looks for the file with no extension first, then tries > > cxx cpp, mm, h, etc. At one point I thought it would be > > better if you had to give the extension. However, at this > > point, it would be hard to change all the projects using > > cmake. I guess it could be a style for list files, that you > > should use the full file name, but I would not want to > > break/change existing projects. > > > > -Bill > > > > > > At 03:40 PM 1/22/2002 -0500, Brad King wrote: > > > > > > >---------- Forwarded message ---------- > > >Date: Tue, 22 Jan 2002 13:49:28 -0500 > > >From: "Lorensen, William E (CRD)" > > >To: cmake@public.kitware.com > > >Subject: [Cmake] SOURCE_FILES default extension > > > > > >How does cmake find the extension to use in the SOURCE_FILES > > statement? > > > > > >I just had an example that used VTK and ITK. My SOURCE_FILES line > > >looked like this SOURCE_FILES(Distance_SRCS Distance > > >Options > > >) > > > > > >The first time cmake generated the Makefile, it correctly > > guessed the > > >extension as "cxx". I successfully built the program (called > > Distance). > > >Then I edited the source file and did another gmake. cmake > > generated a > > >new Makefile with the compile line using the executable name rather > > >than the .cxx file. Seems that the second time, it found > > that the file > > >listed in the SOURCE_FILES was there (the executable this time) and > > >messed up my Makefile. If I remove the Distance file and > > rerun cmake, > > >it generates the correct Makefile. > > > > > >To fix the problem, I changed my command to: > > > > > >SOURCE_FILES(Distance_SRCS > > >Distance.cxx > > >Options.cxx > > >) > > > > > >and all was fine. > > > > > >Seems that cmake should REQUIRE an extension on these source files. > > > > > >Bill > > > > > > > > >_______________________________________________ > > >Cmake mailing list > > >Cmake@public.kitware.com > > >http://public.kitware.com/mailman/listinfo/cmake > > > > _______________________________________________ > > Cmake mailing list > > Cmake@public.kitware.com > > http://public.kitware.com/mailman/listinfo/cma> ke > > > > > >_______________________________________________ >Cmake mailing list >Cmake@public.kitware.com >http://public.kitware.com/mailman/listinfo/cmake From millerjv@crd.ge.com Thu Jan 24 13:39:28 2002 From: millerjv@crd.ge.com (Miller, James V (CRD)) Date: Thu, 24 Jan 2002 08:39:28 -0500 Subject: [Cmake] Borland and NMake builds Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1A4DC.8B8FEBF0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A4DC.8B8FEBF0" ------_=_NextPart_001_01C1A4DC.8B8FEBF0 Content-Type: text/plain; charset="iso-8859-1" Do the Borland and NMake builds put executables in "configuration" subdirectories? I.e. do they put executables in a "Release" or "Debug" or "RelWithDebInfo", etc. subdirectory? When Dart looks for tests to run, it looks in the current directory, then the subdirectories "Release", "Debug", "MinSizeRel", and "RelWithDebInfo" (in that order). The first directory that has an executable with the proper name is the one that it runs. Unfortunately, this means if you did a Release build of your project, then ran a Nightly or Experimental using the Debug configuration, Dart would build the Debug version but run the Release versions of the exe's as the tests. These Release exe's could be very far out of date with the current source tree. What I would like to do for msdev builds, it peek at the MAKE_COMMAND and decide what configuration was built by Dart and only look for executables in the current directory and that specific configuration subdirectory. This will work fine for msdev builds. But I do not know what the impact to Borland or NMake builds may be. I'd like to remove the naive search pattern if it is not needed for the Borland and NMake builds. If the Borland and NMake builds do put executables in configuration specific subdirectories, what does the MAKE_COMMAND look like to specify the configuration? Jim Miller _____________________________________ Visualization & Computer Vision GE Corporate Research & Development Bldg. KW, Room C218B P.O. Box 8, Schenectady NY 12301 millerjv@crd.ge.com < mailto:millerjv@crd.ge.com > (518) 387-4005, Dial Comm: 8*833-4005, Cell: (518) 505-7065, Fax: (518) 387-6981 ------_=_NextPart_001_01C1A4DC.8B8FEBF0 Content-Type: text/html; charset="iso-8859-1"

Do the Borland and NMake builds put executables in "configuration" subdirectories? I.e. do they put executables in a "Release" or "Debug" or "RelWithDebInfo", etc. subdirectory?

When Dart looks for tests to run, it looks in the current directory, then the subdirectories "Release", "Debug", "MinSizeRel", and "RelWithDebInfo" (in that order). The first directory that has an executable with the proper name is the one that it runs.

Unfortunately, this means if you did a Release build of your project, then ran a Nightly or Experimental using the Debug configuration, Dart would build the Debug version but run the Release versions of the exe's as the tests. These Release exe's could be very far out of date with the current source tree.

What I would like to do for msdev builds, it peek at the MAKE_COMMAND and decide what configuration was built by Dart and only look for executables in the current directory and that specific configuration subdirectory.

This will work fine for msdev builds. But I do not know what the impact to Borland or NMake builds may be. I'd like to remove the naive search pattern if it is not needed for the Borland and NMake builds. If the Borland and NMake builds do put executables in configuration specific subdirectories, what does the MAKE_COMMAND look like to specify the configuration?

------_=_NextPart_001_01C1A4DC.8B8FEBF0-- ------_=_NextPart_000_01C1A4DC.8B8FEBF0 Content-Type: application/octet-stream; name="Miller, James V (CRD).vcf" Content-Disposition: attachment; filename="Miller, James V (CRD).vcf" BEGIN:VCARD VERSION:2.1 N:Miller;James FN:Miller, James V (CRD) ORG:CRD;ESL TITLE:Computer Scientist TEL;WORK;VOICE:*833-4005 TEL;WORK;VOICE:1 518 387-4005 ADR;WORK:;KW-C218B;P.O. Box 8;Schenectady;New York;12301;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:KW-C218B=0D=0AP.O. Box 8=0D=0ASchenectady, New York 12301=0D=0AUSA EMAIL;PREF;INTERNET:millerjv@crd.ge.com REV:20010420T140329Z END:VCARD ------_=_NextPart_000_01C1A4DC.8B8FEBF0-- From bill.hoffman@kitware.com Thu Jan 24 13:51:43 2002 From: bill.hoffman@kitware.com (William A. Hoffman) Date: Thu, 24 Jan 2002 08:51:43 -0500 Subject: [Cmake] Borland and NMake builds In-Reply-To: Message-ID: <5.0.2.1.0.20020124085037.02f21208@pop.nycap.rr.com> Borland and nmake work just like unix. There are no configuration subdirectories. Release or Debug, is set by changing a flag value in the cache. -Bill At 08:39 AM 1/24/2002 -0500, Miller, James V (CRD) wrote: >Do the Borland and NMake builds put executables in "configuration" >subdirectories? I.e. do they put executables in a "Release" or "Debug" or >"RelWithDebInfo", etc. subdirectory? > >When Dart looks for tests to run, it looks in the current directory, then >the subdirectories "Release", "Debug", "MinSizeRel", and "RelWithDebInfo" >(in that order). The first directory that has an executable with the >proper name is the one that it runs. > >Unfortunately, this means if you did a Release build of your project, then >ran a Nightly or Experimental using the Debug configuration, Dart would >build the Debug version but run the Release versions of the exe's as the >tests. These Release exe's could be very far out of date with the current >source tree. > >What I would like to do for msdev builds, it peek at the MAKE_COMMAND and >decide what configuration was built by Dart and only look for executables >in the current directory and that specific configuration subdirectory. > >This will work fine for msdev builds. But I do not know what the impact >to Borland or NMake builds may be. I'd like to remove the naive search >pattern if it is not needed for the Borland and NMake builds. If the >Borland and NMake builds do put executables in configuration specific >subdirectories, what does the MAKE_COMMAND look like to specify the >configuration? > > > >Jim Miller >_____________________________________ >Visualization & Computer Vision >GE Corporate Research & Development >Bldg. KW, Room C218B >P.O. Box 8, Schenectady NY 12301 > >millerjv@crd.ge.com <mailto:millerjv@crd.ge.com> >(518) 387-4005, Dial Comm: 8*833-4005, >Cell: (518) 505-7065, Fax: (518) 387-6981 > > From ken.martin@kitware.com Thu Jan 24 13:56:55 2002 From: ken.martin@kitware.com (Ken Martin) Date: Thu, 24 Jan 2002 08:56:55 -0500 Subject: [Cmake] SOURCE_FILES default extension In-Reply-To: <000e01c1a4bb$8bc46c70$bb0c14ac@smirnov> Message-ID: I think we should start using extensions in all our cmakelist files. But for backwards compatibility I don't think we can disallow people from not having the extension. We can 1) add a check so that if the extension was not provided and we find multiple versions of a file we print a warning 2) when multiple matches are found favor foo.cxx foo.c foo.h over plain foo. In general I'm trying to be more careful that new cmakelist files will work with old versions of cmake (or at least provide a message indicating what version someone needs) and that old cmakelist files will work with new version of cmake. Ken > I agree with Bill L: I think it should be mandatory to put > an extension > on the file name. Can't we provide a script which will fix the > cmakelists and give a warning for a short while before breaking > projects? As with VXL, there are inevitably going to be > times when you > need to break things for the sake of sanity, and I think this is an > example. From jrbcast@teleline.es Thu Jan 24 19:27:49 2002 From: jrbcast@teleline.es (=?iso-8859-1?Q?Jos=E9_Rom=E1n_Bilbao?=) Date: Thu, 24 Jan 2002 20:27:49 +0100 Subject: [Cmake] Failed to build Cmake in RH 7.2 Message-ID: <000e01c1a50d$55073c60$ef7c523e@khronos> This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C1A515.97A19590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 I=B4ve a clean Red Hat 7.2 installation. I=B4ve tried to install CMake = in it=B4s latest.=20 i=B4ve tried both methods, precompiled and source code. First gives me = the next: After unzipping and uncompressing the resulting tar file I get to = more files, one README and one tar. When I try to uncompress that tar I = get a message saying it=B4s not a valid tar file. I=B4ve tried to = download it again but it doesn=B4t work. Trying to recompile from sources I make: ./configure; make; make install it seems to configure correctly but when compiling it freezes making = cmCommands.cxx. I=B4ve repeated the procces but it keeps failing. Have you experienced the same ? How can i fix that ? Thanks. ------=_NextPart_000_000B_01C1A515.97A19590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

I=B4ve a clean Red Hat 7.2 = installation. I=B4ve tried=20 to install CMake in it=B4s latest.

i=B4ve tried both methods, precompiled = and source=20 code. First gives me the next:

After unzipping and=20 uncompressing the resulting tar file I get to more files, one README and = one=20 tar. When I try to uncompress that tar I get a message saying it=B4s not = a valid=20 tar file. I=B4ve tried to download it again but it doesn=B4t = work.

Trying to recompile from sources I=20 make:

./configure; make; = make=20 install

it seems to = configure correctly=20 but when compiling it freezes making cmCommands.cxx. I=B4ve repeated the = procces=20 but it keeps failing.

Have you experienced the same = ?

How can i fix that ?

Thanks.

------=_NextPart_000_000B_01C1A515.97A19590-- From millerjv@crd.ge.com Thu Jan 24 19:32:49 2002 From: millerjv@crd.ge.com (Miller, James V (CRD)) Date: Thu, 24 Jan 2002 14:32:49 -0500 Subject: [Cmake] Failed to build Cmake in RH 7.2 Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A50D.E88FCA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable cmCommands takes a long long time to compile. It is the "majority" of = the system. [Jim Miller (CRD)]=20 -----Original Message----- From: Jos=E9 Rom=E1n Bilbao [mailto:jrbcast@teleline.es] Sent: Thursday, January 24, 2002 2:28 PM To: cmake@public.kitware.com Subject: [Cmake] Failed to build Cmake in RH 7.2 Hi,=20 =20 I=B4ve a clean Red Hat 7.2 installation. I=B4ve tried to install CMake = in it=B4s latest.=20 =20 i=B4ve tried both methods, precompiled and source code. First gives me = the next: =20 After unzipping and uncompressing the resulting tar file I get to = more files, one README and one tar. When I try to uncompress that tar I get a message saying it=B4s = not a valid tar file. I=B4ve tried to download it again but it doesn=B4t work. =20 Trying to recompile from sources I make: =20 ./configure; make; make install =20 it seems to configure correctly but when compiling it freezes = making cmCommands.cxx. I=B4ve repeated the procces but it keeps failing. =20 Have you experienced the same ? How can i fix that ? =20 Thanks. ------_=_NextPart_001_01C1A50D.E88FCA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

cmCommands takes=20 a long long time to compile. It is the "majority" of the=20 system.

[Jim = Miller=20 (CRD)]

-----Original=20 Message-----
From: Jos=E9 Rom=E1n Bilbao=20 [mailto:jrbcast@teleline.es]
Sent: Thursday, January 24, 2002 = 2:28=20 PM
To: cmake@public.kitware.com
Subject: [Cmake] = Failed to=20 build Cmake in RH 7.2

Hi,

I=B4ve a clean Red Hat 7.2 = installation. I=B4ve tried=20 to install CMake in it=B4s latest.

i=B4ve tried both methods, = precompiled and source=20 code. First gives me the next:

    After unzipping = and=20 uncompressing the resulting tar file I get to more files, one README = and one=20 tar. When I try to uncompress that tar I get a message saying it=B4s = not a valid=20 tar file. I=B4ve tried to download it again but it doesn=B4t = work.

Trying to recompile from sources I=20 make:

    ./configure; = make; make=20 install

    it seems to = configure=20 correctly but when compiling it freezes making cmCommands.cxx. I=B4ve = repeated=20 the procces but it keeps failing.

Have you experienced the same = ?

How can i fix that ?

Thanks.

------_=_NextPart_001_01C1A50D.E88FCA60-- From bill.hoffman@kitware.com Thu Jan 24 22:49:55 2002 From: bill.hoffman@kitware.com (William A. Hoffman) Date: Thu, 24 Jan 2002 17:49:55 -0500 Subject: [Cmake] Failed to build Cmake in RH 7.2 In-Reply-To: Message-ID: <5.0.2.1.0.20020124174852.02f21038@pop.nycap.rr.com> Be patient cmCommands.cxx can take a long time to compile. You could also download the binaries for cmake 1.2. -Bill At 02:32 PM 1/24/2002 -0500, Miller, James V (CRD) wrote: >cmCommands takes a long long time to compile. It is the "majority" of the= =20 >system. > >[Jim Miller (CRD)] > -----Original Message----- >From: Jos=E9 Rom=E1n Bilbao [mailto:jrbcast@teleline.es] >Sent: Thursday, January 24, 2002 2:28 PM >To: cmake@public.kitware.com >Subject: [Cmake] Failed to build Cmake in RH 7.2 >Hi, > >I=B4ve a clean Red Hat 7.2 installation. I=B4ve tried to install CMake in= it=B4s=20 >latest. > >i=B4ve tried both methods, precompiled and source code. First gives me the= =20 >next: > > After unzipping and uncompressing the resulting tar file I get to=20 > more files, one README and one tar. When I try to uncompress that tar I=20 > get a message saying it=B4s not a valid tar file. I=B4ve tried to download= it=20 > again but it doesn=B4t work. > >Trying to recompile from sources I make: > > ./configure; make; make install > > it seems to configure correctly but when compiling it freezes making= =20 > cmCommands.cxx. I=B4ve repeated the procces but it keeps failing. > >Have you experienced the same ? >How can i fix that ? > >Thanks. From jrbcast@teleline.es Fri Jan 25 00:04:02 2002 From: jrbcast@teleline.es (=?iso-8859-1?Q?Jos=E9_Rom=E1n_Bilbao_Castro?=) Date: Fri, 25 Jan 2002 01:04:02 +0100 Subject: [Cmake] Problems installing cmake Message-ID: <000201c1a533$f4ad7c90$0970523e@khronos> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1A53C.2DD35550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I=B4ve tried to install cmake from sources in RH 7.2. It failed because = hanged up my computer when compiling cmCommands.cxx (More than 30 = minutes compiling and system didn=B4t respond). Now I=B4m trying with precompiled ones. I make the next: gunzip ...tar.gz tar -xvf ...tar Then i get two files, one .tar and README, but when I try to extract = the tar it seem not to be recognized. What can I do? What am I doing = bad? What should I do to uncompress it correctly? Thanks, ------=_NextPart_000_0005_01C1A53C.2DD35550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

I=B4ve tried to install cmake from = sources in RH 7.2.=20 It failed because hanged up my computer when compiling cmCommands.cxx = (More than=20 30 minutes compiling and system didn=B4t respond).

Now I=B4m trying with precompiled ones. = I make the=20 next:

gunzip = ...tar.gz

tar -xvf = ...tar

Then i get two = files, one .tar=20 and README, but when I try to extract the tar it seem not to be = recognized. What=20 can I do? What am I doing bad? What should I do to uncompress it=20 correctly?

Thanks,

------=_NextPart_000_0005_01C1A53C.2DD35550-- From geoff@robots.ox.ac.uk Fri Jan 25 10:06:42 2002 From: geoff@robots.ox.ac.uk (Geoffrey Cross) Date: Fri, 25 Jan 2002 10:06:42 -0000 Subject: [Cmake] Failed to build Cmake in RH 7.2 In-Reply-To: <5.0.2.1.0.20020124174852.02f21038@pop.nycap.rr.com> Message-ID: <000f01c1a587$fdcb6d60$bb0c14ac@smirnov> I had this problem at some point under Solaris using gcc version something-new-but-can't-remember-which. It seems to be related to using the -O2 flag, and causes the compiler to hang indefinitely. Try removing the flag. This is a known compiler bug, and not a bug in Cmake. Geoff. > -----Original Message----- > From: cmake-admin@public.kitware.com=20 > [mailto:cmake-admin@public.kitware.com] On Behalf Of William=20 > A. Hoffman > Sent: Thursday, January 24, 2002 10:50 PM > To: 'Jos=E9 Rom=E1n Bilbao'; cmake@public.kitware.com > Subject: RE: [Cmake] Failed to build Cmake in RH 7.2 >=20 >=20 > Be patient cmCommands.cxx can take a long time to compile. > You could also download the binaries for cmake 1.2. >=20 > -Bill >=20 >=20 > At 02:32 PM 1/24/2002 -0500, Miller, James V (CRD) wrote: > >cmCommands takes a long long time to compile. It is the=20 > "majority" of=20 > >the > >system. > > > >[Jim Miller (CRD)] > > -----Original Message----- > >From: Jos=E9 Rom=E1n Bilbao [mailto:jrbcast@teleline.es] > >Sent: Thursday, January 24, 2002 2:28 PM > >To: cmake@public.kitware.com > >Subject: [Cmake] Failed to build Cmake in RH 7.2 > >Hi, > > > >I=B4ve a clean Red Hat 7.2 installation. I=B4ve tried to install=20 > CMake in=20 > >it=B4s > >latest. > > > >i=B4ve tried both methods, precompiled and source code. First gives = me=20 > >the > >next: > > > > After unzipping and uncompressing the resulting tar=20 > file I get to > > more files, one README and one tar. When I try to=20 > uncompress that tar I=20 > > get a message saying it=B4s not a valid tar file. I=B4ve tried=20 > to download it=20 > > again but it doesn=B4t work. > > > >Trying to recompile from sources I make: > > > > ./configure; make; make install > > > > it seems to configure correctly but when compiling it freezes=20 > > making > > cmCommands.cxx. I=B4ve repeated the procces but it keeps failing. > > > >Have you experienced the same ? > >How can i fix that ? > > > >Thanks. >=20 > _______________________________________________ > Cmake mailing list > Cmake@public.kitware.com=20 > http://public.kitware.com/mailman/listinfo/cma> ke >=20 >=20 From lorensen@crd.ge.com Fri Jan 25 13:19:25 2002 From: lorensen@crd.ge.com (Lorensen, William E (CRD)) Date: Fri, 25 Jan 2002 08:19:25 -0500 Subject: [Cmake] WRAP_EXCLUDE_FILES Message-ID: I have a vtk project that has a file (foo.cxx) that I do not want to wrap. The CMakeLists.txt file has a WRAP_EXCLUDE_FILE(foo.cxx) cmake keeps creating a Makefile that tries to warp the file. Also, the file foo.cxx include a file foo.hpp (not foo.h), but cmake keeps building a depend file that has a foo.h. Ideas, Bill From brad.king@kitware.com Fri Jan 25 15:09:55 2002 From: brad.king@kitware.com (Brad King) Date: Fri, 25 Jan 2002 10:09:55 -0500 (EST) Subject: [Cmake] WRAP_EXCLUDE_FILES In-Reply-To: Message-ID: Hi Bill, > I have a vtk project that has a file (foo.cxx) that I do not want to > wrap. The CMakeLists.txt file has a WRAP_EXCLUDE_FILE(foo.cxx) The wrappers are built from the header files, not the .cxx files. Has foo.cxx been added to the source list as "foo" or "foo.cxx"? > Also, the file foo.cxx include a file foo.hpp (not foo.h), but cmake > keeps building a depend file that has a foo.h. I can't duplicate this with a foo.cxx that has #include "foo.hpp". The generated dependency is okay. However, it looks like the wrapping code may assume that the extension of the class header to be wrapped is ".h". This may be interacting with the lack of WRAP_EXCLUDE_FILE. -Brad From brad.king@kitware.com Fri Jan 25 15:12:10 2002 From: brad.king@kitware.com (Brad King) Date: Fri, 25 Jan 2002 10:12:10 -0500 (EST) Subject: [Cmake] Problems installing cmake In-Reply-To: <000201c1a533$f4ad7c90$0970523e@khronos> Message-ID: > Now I=B4m trying with precompiled ones. I make the next: >=20 > gunzip ...tar.gz > tar -xvf ...tar >=20 > Then i get two files, one .tar and README, but when I try to > extract the tar it seem not to be recognized. What can I do? What am I > doing bad? What should I do to uncompress it correctly? I just checked, and it looks like we accidentally compressed the internal tarball, but left off the .gz extension. I have replaced the tarball on the web page and in the FTP directory. The new one should untar correctly. If you downloaded with a browser, be sure to clear the browser's cache, or it may give you the same file again. You can also just rename the internal tarball to have .tar.gz and then use tar xvzf to extract it. -Brad From lorensen@crd.ge.com Fri Jan 25 15:09:52 2002 From: lorensen@crd.ge.com (Lorensen, William E (CRD)) Date: Fri, 25 Jan 2002 10:09:52 -0500 Subject: [Cmake] WRAP_EXCLUDE_FILES Message-ID: What should I try? -----Original Message----- From: Brad King [mailto:brad.king@kitware.com] Sent: Friday, January 25, 2002 10:10 AM To: Lorensen, William E (CRD) Cc: CMake Subject: Re: [Cmake] WRAP_EXCLUDE_FILES Hi Bill, > I have a vtk project that has a file (foo.cxx) that I do not want to > wrap. The CMakeLists.txt file has a WRAP_EXCLUDE_FILE(foo.cxx) The wrappers are built from the header files, not the .cxx files. Has foo.cxx been added to the source list as "foo" or "foo.cxx"? > Also, the file foo.cxx include a file foo.hpp (not foo.h), but cmake > keeps building a depend file that has a foo.h. I can't duplicate this with a foo.cxx that has #include "foo.hpp". The generated dependency is okay. However, it looks like the wrapping code may assume that the extension of the class header to be wrapped is ".h". This may be interacting with the lack of WRAP_EXCLUDE_FILE. -Brad From wheeler@crd.ge.com Sat Jan 26 13:27:39 2002 From: wheeler@crd.ge.com (Wheeler, Fred (CRD)) Date: Sat, 26 Jan 2002 08:27:39 -0500 Subject: [Cmake] Using EXECUTABLE_OUTPUT_PATH breaks "make test" Message-ID: For VXL, if I set EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH all of the execs and libs go where specified. But then, make test cannot find the test execs. Is this a cmake issue or a vxl issue? Is there a work-around? Thanks, Fred Wheeler From wheeler@crd.ge.com Sat Jan 26 18:06:30 2002 From: wheeler@crd.ge.com (Wheeler, Fred (CRD)) Date: Sat, 26 Jan 2002 13:06:30 -0500 Subject: [Cmake] Re: slowness of Cmake.pdf update Message-ID: Both gzip and zip (Unix version of PK zip) compress Cmake.pdf from 1.7 M down to about 100 k. I suggest putting CMake.pdf.zip and possibly also Cmake.pdf.gz on the CVS server. I think most Unix machines have unzip installed, so just going with Cmake.pdf.zip might be ok. Fred Wheeler -- Fred Wheeler, GE CRD, KWC-303 Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) From wheeler@crd.ge.com Sat Jan 26 18:09:47 2002 From: wheeler@crd.ge.com (Wheeler, Fred (CRD)) Date: Sat, 26 Jan 2002 13:09:47 -0500 Subject: [Cmake] Re: slowness of Cmake.pdf update Message-ID: [[ OK, I just read the rest of the messages on this subject and realize that using cvs -zN will basically accomplish the same thing, only in a more portable way. ]] > Both gzip and zip (Unix version of PK zip) compress Cmake.pdf from 1.7 M down to about 100 k. I suggest putting CMake.pdf.zip and possibly also Cmake.pdf.gz on the CVS server. I think most Unix machines have unzip installed, so just going with Cmake.pdf.zip might be ok. Fred Wheeler -- Fred Wheeler, GE CRD, KWC-303 Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) From ken.martin@kitware.com Mon Jan 28 14:46:57 2002 From: ken.martin@kitware.com (Ken Martin) Date: Mon, 28 Jan 2002 09:46:57 -0500 Subject: [Cmake] Using EXECUTABLE_OUTPUT_PATH breaks "make test" In-Reply-To: Message-ID: This is probably a CMakeLists problem (you could say cmake should handle it but...) Basically Dart (and ctest which is what make test does) by default look for executables in the binary tree in the subdirectories where the tests were added to the cmake lists files. They also look in subdirectories such as Release, Debug etc. When you use EXECUTABLE_OUTPUT_PATH the executable get placed somewhere else. What I have done in the past is in the top level CMake file # where will executable tests be written ? IF (EXECUTABLE_OUTPUT_PATH) SET (CXX_TEST_PATH ${EXECUTABLE_OUTPUT_PATH}) ELSE (EXECUTABLE_OUTPUT_PATH) SET (CXX_TEST_PATH .) ENDIF (EXECUTABLE_OUTPUT_PATH) and when I add a test ADD_TEST(ObjectFactory ${CXX_TEST_PATH}/ObjectFactory) Ken From wheeler@crd.ge.com Mon Jan 28 15:10:58 2002 From: wheeler@crd.ge.com (Wheeler, Fred (CRD)) Date: Mon, 28 Jan 2002 10:10:58 -0500 Subject: [Cmake] Using EXECUTABLE_OUTPUT_PATH breaks "make test" Message-ID: Ken, thanks. Why the CXX_ prefix? Is there a corresponding C_TEST_PATH, or does cmake use CXX_TEST_PATH to find all of the test executables? I'm going to try the following cmake flags... -DEXECUTABLE_OUTPUT_PATH:PATH=$SR/vxl_bld/bin -DLIBRARY_OUTPUT_PATH:PATH=$SR/vxl_bld/lib -DCXX_TEST_PATH:PATH=$SR/vxl_bld/bin Fred Wheeler -----Original Message----- From: Ken Martin [mailto:ken.martin@kitware.com] Sent: Monday, January 28, 2002 9:47 AM To: Wheeler, Fred (CRD); cmake@public.kitware.com Subject: RE: [Cmake] Using EXECUTABLE_OUTPUT_PATH breaks "make test" This is probably a CMakeLists problem (you could say cmake should handle it but...) Basically Dart (and ctest which is what make test does) by default look for executables in the binary tree in the subdirectories where the tests were added to the cmake lists files. They also look in subdirectories such as Release, Debug etc. When you use EXECUTABLE_OUTPUT_PATH the executable get placed somewhere else. What I have done in the past is in the top level CMake file # where will executable tests be written ? IF (EXECUTABLE_OUTPUT_PATH) SET (CXX_TEST_PATH ${EXECUTABLE_OUTPUT_PATH}) ELSE (EXECUTABLE_OUTPUT_PATH) SET (CXX_TEST_PATH .) ENDIF (EXECUTABLE_OUTPUT_PATH) and when I add a test ADD_TEST(ObjectFactory ${CXX_TEST_PATH}/ObjectFactory) Ken From millerjv@crd.ge.com Mon Jan 28 15:24:17 2002 From: millerjv@crd.ge.com (Miller, James V (CRD)) Date: Mon, 28 Jan 2002 10:24:17 -0500 Subject: [Cmake] Using EXECUTABLE_OUTPUT_PATH breaks "make test" Message-ID: The CXX_TEST_PATH is just a variable name. It gets expanded in Ken's example in the ADD_TEST command. This variable could have been "FOO" or anything else. Just setting the CXX_TEST_PATH or whatever you choose to call the variable is not enough. The ADD_TEST commands (in the CMakeLists.txt files) need to know where executables are going to be located. -----Original Message----- From: Wheeler, Fred (CRD) Sent: Monday, January 28, 2002 10:11 AM To: 'Ken Martin' Cc: cmake@public.kitware.com Subject: RE: [Cmake] Using EXECUTABLE_OUTPUT_PATH breaks "make test" Ken, thanks. Why the CXX_ prefix? Is there a corresponding C_TEST_PATH, or does cmake use CXX_TEST_PATH to find all of the test executables? I'm going to try the following cmake flags... -DEXECUTABLE_OUTPUT_PATH:PATH=$SR/vxl_bld/bin -DLIBRARY_OUTPUT_PATH:PATH=$SR/vxl_bld/lib -DCXX_TEST_PATH:PATH=$SR/vxl_bld/bin Fred Wheeler -----Original Message----- From: Ken Martin [mailto:ken.martin@kitware.com] Sent: Monday, January 28, 2002 9:47 AM To: Wheeler, Fred (CRD); cmake@public.kitware.com Subject: RE: [Cmake] Using EXECUTABLE_OUTPUT_PATH breaks "make test" This is probably a CMakeLists problem (you could say cmake should handle it but...) Basically Dart (and ctest which is what make test does) by default look for executables in the binary tree in the subdirectories where the tests were added to the cmake lists files. They also look in subdirectories such as Release, Debug etc. When you use EXECUTABLE_OUTPUT_PATH the executable get placed somewhere else. What I have done in the past is in the top level CMake file # where will executable tests be written ? IF (EXECUTABLE_OUTPUT_PATH) SET (CXX_TEST_PATH ${EXECUTABLE_OUTPUT_PATH}) ELSE (EXECUTABLE_OUTPUT_PATH) SET (CXX_TEST_PATH .) ENDIF (EXECUTABLE_OUTPUT_PATH) and when I add a test ADD_TEST(ObjectFactory ${CXX_TEST_PATH}/ObjectFactory) Ken _______________________________________________ Cmake mailing list Cmake@public.kitware.com http://public.kitware.com/mailman/listinfo/cmake From brad.king@kitware.com Mon Jan 28 15:32:20 2002 From: brad.king@kitware.com (Brad King) Date: Mon, 28 Jan 2002 10:32:20 -0500 (EST) Subject: [Cmake] Using EXECUTABLE_OUTPUT_PATH breaks "make test" In-Reply-To: Message-ID: > Why the CXX_ prefix? Is there a corresponding C_TEST_PATH, or does > cmake use CXX_TEST_PATH to find all of the test executables? The variable means nothing special for CMake. In Ken's example, he set it in the top-level CMakeLists.txt file, and then used it whenever a test was added. Top-level. Choose where the tests should be found: > # where will executable tests be written ? > IF (EXECUTABLE_OUTPUT_PATH) > SET (CXX_TEST_PATH ${EXECUTABLE_OUTPUT_PATH}) > ELSE (EXECUTABLE_OUTPUT_PATH) > SET (CXX_TEST_PATH .) > ENDIF (EXECUTABLE_OUTPUT_PATH) Anywhere a test is added uses the variable for the full path: > ADD_TEST(ObjectFactory ${CXX_TEST_PATH}/ObjectFactory) CMake does not treat this special in any way. The code is merely programming the correct path for the executable to be found. Similar code should be written for VXL. -Brad From perera@cs.rpi.edu Thu Jan 31 15:38:39 2002 From: perera@cs.rpi.edu (Amitha Perera) Date: Thu, 31 Jan 2002 10:38:39 -0500 Subject: [Cmake] Re: library dependency information In-Reply-To: <5.0.2.1.0.20020118064757.02d33130@pop.nycap.rr.com>; from bill.hoffman@kitware.com on Fri, Jan 18, 2002 at 06:55:43AM -0500 References: <5.0.2.1.0.20020117163730.02d3d680@pop.nycap.rr.com> <20020117120716.F61748@cs.rpi.edu> <20020117114007.E61748@cs.rpi.edu> <5.0.2.1.0.20020117114733.03dfe7a0@pop.nycap.rr.com> <20020117120716.F61748@cs.rpi.edu> <20020117143228.H61748@cs.rpi.edu> <5.0.2.1.0.20020117163730.02d3d680@pop.nycap.rr.com> <20020117164730.J61748@cs.rpi.edu> <5.0.2.1.0.20020118064757.02d33130@pop.nycap.rr.com> Message-ID: <20020131103839.A29432@cs.rpi.edu> It looks like it's going to take me a long while to get time to do this properly. I apologise to any that have been eagerly awaiting it. Amitha. On Fri, Jan 18, 2002 at 06:55:43AM -0500, William A. Hoffman wrote: > So, to summarize: > > 1. You will add an option that removes duplicates just like the -L options > are currently removed. > 2. For static builds you will use the libraries that have been linked to > libraries to get all the > needed libraries for an exectuable: > So if you have: > libA -> libB > Then you have an executable foo.exe that has a TARGET_LINK_LIBRARY(foo A) > you will know to add the -lB in the right order. > > If projects are building on Windows all libraries will have the list of > libraries that they link against, so most > projects will have this information. > > You will have to make a cache entry to store the information. Something like: > A_LIBRARY_LINKS:INTERNAL:B > > There is already some stuff like that going on in the cache, look at your > cache to see. > > Also, I like the idea of moving this into the generator parent class. We > could add a method there to collapse > the library path and library link options. The code is duplicated in the > two generators now. > > -Bill From perera@cs.rpi.edu Sun Jan 6 20:13:37 2002 From: perera@cs.rpi.edu (Amitha Perera) Date: Sun, 6 Jan 2002 15:13:37 -0500 Subject: [Cmake] Symbolic pathname translation Message-ID: <20020106151337.K11388@cs.rpi.edu> Hi all I've just committed a change that allows the pathnames generated by CMake to maintain symbolic links. If cmake is invoked with two paths--the first to the source directory, the second to the output directory--those paths will be used "as is" to refer to the roots of the source and output trees. I call this pathname translation, and is only enabled with this special two directory invocation. It shouldn't break cmake for anyone. If it does, please let me know and I'll try fix it. To illustrate further: suppose your source and output directories are /my/src and /my/bin, and on your machine (my.machine), these are symbolic links to a locally mounted disk: my.machine: /my/src links to /localdisk/src my.machine: /my/bin links to /localdisk/bin If you run CMake as normal cd /my/bin; cmake /my/src all the paths will refer to /localdisk/src and /localdisk/bin. Suppose these disks are network mounted on a different machine (other.machine) as other.machine: /my/src links to /nfs/my.machine/src other.machine: /my/bin links to /nfs/my.machine/bin Then, attempting to compile the source or to run dynamically linked executables on other.machine will fail because all references to /localdisk are invalid. If, my.machine, you run CMake with pathname translation cd /localdisk/bin; cmake /my/src /my/bin Then CMake will automatically replace all references to /localdisk/src with /my/src and to /localdisk/bin with /my/bin. Assuming /my/src and /my/bin are valid aliases network-wide, then all is well on other.machine. For pathname translation to be enabled, the symbolic source and output directories must be absolute paths, and the output directory must refer to the current directory. (I.e. cmake must be run from the output directory.) Amitha. From millerjv@crd.ge.com Mon Jan 7 18:42:55 2002 From: millerjv@crd.ge.com (Miller, James V (CRD)) Date: Mon, 7 Jan 2002 13:42:55 -0500 Subject: [Cmake] What "path" do custom commands use? Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C197AB.1F0270E0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C197AB.1F0270E0" ------_=_NextPart_001_01C197AB.1F0270E0 Content-Type: text/plain; charset="iso-8859-1" I am having a problem with the cmFLTKWrapUICommand when it is run on the PC. When fluid.exe is run, it cannot find a required dll. The specific dll is one that Intel C++ provides which is what I used to build fltk. I can run fluid from the command line and it works fine. However, when DevStudio runs fluid as a custom command, the search path does not include the directory that has the Intel C++ dlls. This directory is in my path when I run from the comand line. Do custom commands have a special "path" associated with them? Is this a DevStudio problem? Jim Miller _____________________________________ Visualization & Computer Vision GE Corporate Research & Development Bldg. KW, Room C218B P.O. Box 8, Schenectady NY 12301 millerjv@crd.ge.com < mailto:millerjv@crd.ge.com > (518) 387-4005, Dial Comm: 8*833-4005, Cell: (518) 505-7065, Fax: (518) 387-6981 ------_=_NextPart_001_01C197AB.1F0270E0 Content-Type: text/html; charset="iso-8859-1"