[squid-dev] [RFC] build chain updates

Amos Jeffries squid3 at treenet.co.nz
Fri Oct 10 02:26:39 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Now that we have a basic git repository available (Thanks Henrik!) I
am looking at Visual Studio builds again.


We seems to have a few options.

1a) The SquidNT style of manually built and maintained VS
.sln/.vcxproj files comitted to the squid-2 tree.

This gives us complete control of what gets built by VS, dependencies,
and we can even do convenience libraries as separate sub-projects.

However, it gives us two completely separate toolchains to maintain. I
am working this way already as I test each components build. But given
the amount of work to get it in place any faster alternatives would be
welcome.

1b) Using automake to generate the .xvcproj files.

I found one open source project doing things this way a year or so
back. It sounds wonderful, but IIRC still required some environment
able to run ./configure with the desired options first.

Am looking at this to automate part of 1a. Even if it can only do
.xvcproj files thats vast reduction in work.


3) Using CMake to build alternative toolchain scripts.

The most widely documented method of automating VS builds of open
source code. However, taking a close look at the documentation CMake
does not support out-of-source builds in an easily maintained way.
Given our past history with auto-generated source files this could be
a recipe for nasty mistakes and build farm problems.


4) Creating a VS project that runs autoconf/automake.

Just mentioning for completeness. iCelero had a system based on this
running. It produced all the binaries and outputs. However, they also
spoke of problems generating debug binaries and Win32 installers based
on that projects output. There was active work at the time trying to
get away from this. It also seems to require some environment able to
run ./configure with the desired options first, though this could be
an artifact of their using MinGW.


Does anyone have more alternatives for me to look at? or preferences?
additional notes on the above? anything?

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUN0PeAAoJELJo5wb/XPRjt04IAMC04CpsmO53ICaR+O60haRW
R78jqaA/eI+trj5+xNPIRKjdJWN71KGekljMPpR5vpBthdrzqM9tqRln5SMWrpO3
6WH5bS7r5FmKfJztPFm/QCDnTIiVyAe4OLy4vLNGl/txrI6LoZ+Is+TZP0zpdGgF
LsH/66LFkQb5UkEQJOVbYnCabQetOSE4IokhA0kB6M3i25iBqQO+pP9oYsdJPb5o
UvAVaTsv8EyDy/b250pqa5zba9Mz40bmIWyyo11GdonhtDCU5G+ILu37Zg/f34eb
tXTmpzrrOl7FdRhmFRVK8zl4Bndvpu4OLc3uxJaAfJSY7zryyISlihevYjgiJPY=
=KKAd
-----END PGP SIGNATURE-----


More information about the squid-dev mailing list