> 1. Curlpp do not officially support VC7, so we shell drop it (unless you
> want to take over this support)
We should drop it.
> 2. I made some cosmetic modifications of the bat file
> - On my WinXp Sp3 "pause" command does not display any message, so I
On my Vista x64 it's the same :)
I just added it but didn't test it.
> prepended it with echo
Ok.
> - It is not clear what "restore" option does. BTW, if it is an option
It creates stub files back from the current solution files.
It's needed if you made some changes to solution files and want to
update stub files to include them. It's used only during development,
then. Restore is a bad name for it. We could change it to 'create-stubs'
or some other.
> (not argument), it should be prefixed with '-' or '/'
It's kind of a command not an argument and commands come usually without
prefix (like hg push). As a command it should be the first argument
though, but because it's optional and used during development only I put
it as the last one. It's all the same to me so we can leave it with '/'
as it's now.
> 3. I also do not have sed tool on Windows.
I didn't have it neither :)
You can download it here
http://gnuwin32.sourceforge.net/packages/sed.htm
> 4. I guess Windows developers will be annoyed that they need to launch
> any command-line tools to compile something in VC. Well, it could be an
I was indeed annoyed when I had to install Perl just to create makefiles
to build OpenSSL. But... it took me only 5 minutes and I think the
process of creating makefiles took care of many things I would have to
take care of myself otherwise.
I agree it's not very handy for users and I would like to be able to
create these files using only system tools.
On the other hand;
- standard system tools are almost non-existent
- it's just one small program
- developers should be able to handle this
> option, but not must. I see the 2 alternatives:
> 4.1 Maintain only one solution/project of the minimal supported
> version (8 in this case). VS will them able to generate VC9 stuff itself.
I remember you proposed it earlier. Not a bad idea.
> 4.2 We shell use this tool ourselves to pre-generate the
> solutions/projects for all supported VSs and add them to repo. I know it
> is not totally correct to keep generated stuff on repo, but advantages
> overweight the disadvantages.
I was thinking the same.
I'm for 4.2
Regards
Piotr
>> And we should add info about copying solution files to the root folder
>> before using them.
>
> This seems error-prone to me (Windows users never read mans ;)), why not
> just adding some 'vc-N' suffixes/prefixes to the solution files themselves?
Because we would have to add this suffixes additionally _inside_ files
to keep references valid. That's an extra work we can avoid by putting
them in two subfolders.
Users need to read README file anyway. Otherwise they won't be able to
successfully build the library, anyway.
Piotr
>> 4.2 We shell use this tool ourselves to pre-generate the
>> solutions/projects for all supported VSs and add them to repo. I know it is
>> not totally correct to keep generated stuff on repo, but advantages
>> overweight the disadvantages.
>
> This is what curl project does with nmake makefiles for different VC
> versions.
Almost. The curl project does not commit generated files in CVS. But we have
scripts that generate files that are automatically included in release
tarballs. Those include nmake makefiles.
--
Thanks for info.
We should do the same then.
Piotr