Chris Frey schrieb:
> On Thu, Aug 25, 2005 at 03:36:26PM +0200, Thomas Werth wrote:
>
>>>>In Team based development each dev/pc has different install dir for
>>>>mysqlpp.
>>>
>>>
>>>IMHO, that's the real problem you should be solving. A team without
>>>standards isn't much of a "team".
>>
>>It's a question about where to stop boundings of standards. Extension
>>Path is something that shouldn't belong to a project. It's important to
>>access extensions but not in a special path. You surely won't shrink
>>mysql++ down to only use one fixed sql statement, so requirement is to
>>supply a valid sql statement. Same here. No matter where Studio will
>>find extension important is to find them.
>
>
> Just have to add my $0.02 here... I have to agree with Warren. When you
> put library directory paths in the global settings, suddenly you've lost
> documentation for how to build your project. You've lost flexibility
> in using different library versions for different projects. And you're
> using a global namespace when most people avoid them.
>
> Personally I find the documentation reason the most compelling. When
> I get a project dumped on me that requires some global directory settings,
> I have to look elsewhere to find out what the magic configuration is.
>
> When the directories are specified in the project, all requirements are
> neatly spelled out, and always move with the project itself.
>
> - Chris
>
>
This could still be applied when using different names for debug/release
lib. There's no need to switch to global path for anyone. But in case of
different names once those dll leave debug/release build folder they can
still be identified by name. For example this is helpfull to check for
"right" version when deploying . Usualy every modern c++ libs use this
way ( see qt for example ). I just wondered why mysql++ doesn't go this way.
