[push] unified solution files

2 views
Skip to first unread message

Piotr Dobrogost

unread,
Mar 12, 2009, 4:15:10 PM3/12/09
to curlpp-devel
Andrei

To avoid maintaining two versions of solution files I created common
stubs and a very small batch file to generate files for specific
version of VS from them. I placed them in a new win32 folder.

You can check if it works for you in VC 2005. After this we could
remove old VC8 files from the project.

To make development of solutions files easier the create-vc-
solution.bat file can create new stubs from existing solution files.
To do so you have to give the word 'restore' as the second argument to
it.

Regards
Piotr

Andrei Korostelev

unread,
Mar 13, 2009, 4:12:47 PM3/13/09
to curlpp...@googlegroups.com
I have a couple of remarks:

1. Curlpp do not officially support VC7, so we shell drop it (unless you
want to take over this support)
2. I made some cosmetic modifications of the bat file
- On my WinXp Sp3 "pause" command does not display any message, so I
prepended it with echo
- It is not clear what "restore" option does. BTW, if it is an option
(not argument), it should be prefixed with '-' or '/'

3. I also do not have sed tool on Windows.
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
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.
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.

Piotr Dobrogost

unread,
Mar 13, 2009, 6:42:12 PM3/13/09
to curlpp...@googlegroups.com
Andrei Korostelev wrote:

> 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

p...@1.google.autoera.pl

unread,
Mar 14, 2009, 6:17:00 PM3/14/09
to curlpp-devel
On Mar 13, 9:12 pm, Andrei Korostelev <and...@korostelev.net> wrote:

>   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

In this case we should create vc8 and vc9 subfolders in win32 folder
and put generated files there so that they could have the same names.
The same names are important so that we don't break links between the
files.
And we should add info about copying solution files to the root folder
before using them.

Piotr

Andrei Korostelev

unread,
Mar 15, 2009, 5:48:50 AM3/15/09
to curlpp...@googlegroups.com
> On Mar 13, 9:12 pm, Andrei Korostelev <and...@korostelev.net> wrote:
>
>> 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
>
> In this case we should create vc8 and vc9 subfolders in win32 folder
> and put generated files there so that they could have the same names.
> The same names are important so that we don't break links between the
> files.

I agree.

> 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?

>
> Piotr
> >
>

Piotr Dobrogost

unread,
Mar 15, 2009, 8:37:18 AM3/15/09
to curlpp...@googlegroups.com
Andrei Korostelev wrote:

>> 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

Piotr.Dobrogost

unread,
Apr 5, 2009, 6:47:52 PM4/5/09
to curlpp-devel
On Mar 13, 10:12 pm, Andrei Korostelev <and...@korostelev.net> wrote:

>   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.

Piotr

Daniel Stenberg

unread,
Apr 6, 2009, 4:39:09 AM4/6/09
to curlpp-devel
On Sun, 5 Apr 2009, Piotr.Dobrogost wrote:

>>   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.

--

/ daniel.haxx.se

Piotr Dobrogost

unread,
Apr 6, 2009, 6:28:09 AM4/6/09
to curlpp...@googlegroups.com

Thanks for info.
We should do the same then.

Piotr


Reply all
Reply to author
Forward
0 new messages