The VXL Project

> > ... tagging the repository seems like a lightweight alternative.
[...]
> What about this Saturday night, i.e., 60 hours from now ?

We at RPI think we may be able to get a preliminary configuration for
VC++.NET by the end of the day tomorrow. However, we are not as strong
with the vcl as others in Oxford :-) and may not get it completely
correct the first time. Is VC++.NET worthy of being in the beta2
release, or should we hold on 'till after that?

Amitha.

I wrote:
> We at RPI think we may be able to get a preliminary configuration
> for VC++.NET

We are thinking of re-designing the vcl configuration files (the
vcl/vcl_config*.h files) so that either they are automatically
configured from the .in files (as is done for Unix systems), or else
are just included from vcl/manualconfig/vcl_config*.h. The files in
here will then look at the compiler (with the help of vcl_compiler.h),
and include the appropriate files. As an example,

----------------------------------------
vcl/manualconfig/vcl_config_compiler.h
  #include <vcl_compiler_type.h>

  #if VC_70
  # include "vc70/vcl_config_compiler.h"
  #elif VC_60
  # include "vc60/vcl_config_compiler.h"
  #else
  # error "No manual configuration available for this compiler"
  #endif
----------------------------------------

The subdirectories of vcl/manualconfig/ will contain the actual
configuration files for those compilers that need manual
configurations.

Is there any major objection to this?

This change is straight-forward for the CMake build system, but I
don't know how it will affect the IUE-type makefiles, and other
private build systems.

Thanks,
Amitha.

> Is VC++.NET worthy of being in the beta2
> release, or should we hold on 'till after that?

That's up to you to decide.  If you want to include it, we should probably
shift the release deadline by a week or so, to allow for thorough testing.
The same holds for the vgui changes, I believe.


	Peter.

> We are thinking of re-designing the vcl configuration files (the
> vcl/vcl_config*.h files) so that either they are automatically
> configured from the .in files (as is done for Unix systems)
> ...
> This change is straight-forward for the CMake build system, but I
> don't know how it will affect the IUE-type makefiles, and other
> private build systems.

If all this is done through a configure script, it will not be particular
for a certain build system, so in that case I don't see a problem.
Could you describe the proposed new setup in some more detail?


	Peter.

On Fri, Aug 23, 2002 at 09:21:53AM +0200, Peter Vanroose wrote:
> > Is VC++.NET worthy of being in the beta2
> > release, or should we hold on 'till after that?
> 
> That's up to you to decide.  If you want to include it, we should probably
> shift the release deadline by a week or so, to allow for thorough testing.
> The same holds for the vgui changes, I believe.

I request that we delay the tag to next Saturday, 31 Aug. Hopefully we
can have the VC++.NET and the vgui well tested by then, and can
release vxl beta-2 at the beginning of next month.

Amitha.

On Fri, Aug 23, 2002 at 09:24:03AM +0200, Peter Vanroose wrote:
> > We are thinking of re-designing the vcl configuration files (the
> > vcl/vcl_config*.h files) so that either they are automatically
> > configured from the .in files (as is done for Unix systems)
> > ...
> > This change is straight-forward for the CMake build system, but I
> > don't know how it will affect the IUE-type makefiles, and other
> > private build systems.
> 
> If all this is done through a configure script, it will not be particular
> for a certain build system, so in that case I don't see a problem.
> Could you describe the proposed new setup in some more detail?

It's not much different from the current setup. Right now, the Unix
hosts generate the compiler dependent headers with a configure script,
while VC60 details are manually specified in vcl/config.win32-vc60.

Instead, we suggest that config.win32-vc60 be renamed to config-win32,
with two new subdirectories, vc60 and vc70
    vcl
      +- config.win32
         +- vc60
         +- vc70

Currently, we have in UseVXL.cmake

IF(WIN32)
  IF(NOT CYGWIN)
    INCLUDE_DIRECTORIES(${allvxl_SOURCE_DIR}/vcl/config.win32-VC60)
  ENDIF(NOT CYGWIN)
ENDIF(WIN32)

The "INCLUDE" line would change to 
    INCLUDE_DIRECTORIES(${allvxl_SOURCE_DIR}/vcl/config.win32)

In config.win32, we would have files like
   vcl/config.win32/vcl_compiler_config.h:
       #if _MSC_VER >= 1300
       #  include "vc70/vcl_compiler_config.h"
       #else
       #  include "vc60/vcl_compiler_config.h"
       #endif

The files in vcl/config.win32/vc{6,7}0/vcl_compiler_config.h would
then contain the actual, manually maintained configuration for each
compiler.



An alternative is to have the configurations for both VC60 and VC70 in
a single file. We've found that the two compilers only differ in a few
options. For those options, we could have a check. For example,
suppose VC70 supports partial specialization (it does not). Then, we
could have
  #if VC70
  #  define VCL_CAN_DO_PARTIAL_SPECIALIZATION 1
  #else
  #  define VCL_CAN_DO_PARTIAL_SPECIALIZATION 0
  #endif

Unguarded settings would then apply to both compilers.



Ideally, there would be some way to determine these settings
automatically. I don't think there is any equivalent of configure
scripts for VC++.

Comments?

Amitha.

Not that it helps you now, but it might help in planning.
CMake 1.6 will support TRY_COMPILE.

-Bill



>Ideally, there would be some way to determine these settings
>automatically. I don't think there is any equivalent of configure
>scripts for VC++.
>
>Comments?
>
>Amitha.
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone?  Get a new here for FREE!
>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>_______________________________________________
>Vxl-maintainers mailing list
>Vxl-maintainers@...
>https://lists.sourceforge.net/lists/listinfo/vxl-maintainers