RE: [PATCH] Scripts, generating solution and projects for MSVC/ICC [2]

[Farid Zaripov <Fa...@kyiv.vdiweb.com>]

> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Saturday, September 30, 2006 1:43 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] Scripts, generating solution and 
> projects for MSVC/ICC [2]
> 
> Farid Zaripov wrote:
> >   Patch for scripts of Windows build infrastructure is here:
> > http://people.apache.org/~faridz/windows.diff
> 
> Btw., I noticed that the _RWBUILD_std macro is (still) being 
> #defined. It shouldn't be.
  The _RWBUILD_std macro used to define properly _RWSTD_EXPORT macro.

_defs.h, line 454:
========================
// set up Win32/64 DLL export/import directives
// _DLL - defined by the compiler when either -MD or -MDd is used
// RWDLL - defined for all Rogue Wave(R) products built as shared libs
// _RWSHARED - defined for libstd built/used as a shared lib
#if (defined (_WIN32) || defined (_WIN64)) && \
    (defined (RWDLL)  || defined (_RWSHARED))

#  ifdef _RWBUILD_std
#    define _RWSTD_EXPORT            __declspec (dllexport)
#  else
#    define _RWSTD_EXPORT            __declspec (dllimport)
#  endif   // _RWBUILD_std
========================

  Should we replace #ifdef _RWBUILD_std to #ifdef _RWSTD_LIB_SRC in
_defs.h?

> Also, it would be good to document the variables defined in 
> the .config files. I have an idea what CPPFLAGS might be but 
> what's CONVERT or SLNVER (these are rhetorical questions)? 
> While on the subject of these variables, shouldn't -qnoipo be 
> defined in LDFLAGS rather than in LD?
  CXX, LD, AR variables are used at configure step only. The CPPFLAGS,
LDFLAGS
are used in libraries, examples and tests builds also. Thus LD variable
should contain 
additiona options for configure step. We can rename LDFLAGS to
LDFLAGS.wide and
add LDFLAGS.config=-qnoipo. BTW it seems to me -qnoipo flags is
unnecessary (I just
copied this flags from the previous scripts). All works fine without
this flag.

> And shouldn't we be using cl (or icl) to link instead of invoking the
linker directly?
  I not found where MS recommends invoke cl.exe instead of link.exe to
link files.

Farid.

Re: [PATCH] Scripts, generating solution and projects for MSVC/ICC [2]

[Martin Sebor <se...@roguewave.com>]

Farid Zaripov wrote:
[...]
>   The _RWBUILD_std macro used to define properly _RWSTD_EXPORT macro.

Hmm. I hadn't realized that. _RWBUILD_std is a vestige of the
Rogue Wave build infrastructure (as you might be able to tell
by the odd looking name).

[...]
>   Should we replace #ifdef _RWBUILD_std to #ifdef _RWSTD_LIB_SRC in
> _defs.h?

Yes. It should also key in on _RWSHARED.

> 
> 
>>Also, it would be good to document the variables defined in 
>>the .config files. I have an idea what CPPFLAGS might be but 
>>what's CONVERT or SLNVER (these are rhetorical questions)? 
>>While on the subject of these variables, shouldn't -qnoipo be 
>>defined in LDFLAGS rather than in LD?
> 
>   CXX, LD, AR variables are used at configure step only.

And not when bulding the lib? Why not?

> The CPPFLAGS,
> LDFLAGS
> are used in libraries, examples and tests builds also. Thus LD variable
> should contain 
> additiona options for configure step. We can rename LDFLAGS to
> LDFLAGS.wide and
> add LDFLAGS.config

I think it's best for the config flags to be the same (and under
the same variable) as those used to compile and link the library
to prevent accidental incompatibilities. The flags for examples,
tests, and everything else can be different as long as they stay
binary compatible.

> =-qnoipo. BTW it seems to me -qnoipo flags is
> unnecessary (I just
> copied this flags from the previous scripts). All works fine without
> this flag.

Let's take it out then. IPO could be useful.

> 
> 
>>And shouldn't we be using cl (or icl) to link instead of invoking the
> 
> linker directly?
>   I not found where MS recommends invoke cl.exe instead of link.exe to
> link files.

In general, linkers like to be invoked via the compiler driver.
MSVC's compiler driver, cl, invokes the linker automatically
like other drivers do:
http://msdn2.microsoft.com/en-us/library/9s7c9wdw.aspx
Unless you know of a reason why invoking link.exe directly is
better I think we should use the driver.

Martin