Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too many options for building for MSVC #182

Closed
mardy opened this Issue Nov 29, 2017 · 13 comments

Comments

Projects
5 participants
@mardy
Copy link

mardy commented Nov 29, 2017

Hi there!
I've finally managed to build exiv2 under windows 8 and MSVC 2017, by simply using the CMakeLists.txt located in the project root directory. But before trying this, I spent some time reading the CMake readme file which instead of clarifying the situation made it all more confused. :-)
I tried the contrib/cmake/msvc and the contrib/build/msvc solutions, which were just a waste of time as I couldn't get them to work.

Since the CMakeLists.txt from the project root directory works like a charm, why are these other solutions needed? If they have their reason to exist, I would anyway suggest to update the readme file to recomment the MSVC users to use the main CMakeLists.txt, and clearly specify under which cases the other two methods must be used instead.

@D4N

This comment has been minimized.

Copy link
Contributor

D4N commented Nov 29, 2017

Hi, thanks for your feedback concerning the build system. I believe the msvc project files exist because cmake used to cause some issues on Windows. @clanmills & @tbeu know more about this than me, as I have never build exiv2 on Windows.

We could consider updating the readme if cmake becomes a full replacement for the msvc project files.

@clanmills

This comment has been minimized.

Copy link
Collaborator

clanmills commented Nov 30, 2017

I have just returned from a trip to Vietnam to attend the wedding on Tuan and Alice. Tuan was a Google Summer of Code student in 2013 and contributed "web ready" to Exiv2.

I've done a sync on 'master' and contrib/cmake/msvc builds correctly without any changes. Perhaps @mardy could explain his "waste of time" comment and his concerns will be investigated.

It has been a long-term goal of Exiv2 to adopt CMake as our primary (and preferred) build system. I have maintained the msvc and autotools build environments as they have been working well for years. CMake and Visual Studio have been very challenging to say the least. I added contrib/cmake/msvc in v0.26. The script cmakeBuild.cmd knows how to download and build dependencies such as zlib, expat, and openssl. It is used by the buildserver to perform our daily/weekly/monthly builds.

I was delighted when @piponazo joined Team Exiv2 in July and has been contributing in many areas including a rewrite of the CMake code. @piponazo has been a strong advocate the conan will be able to deal correctly with dependencies on all platforms including many editions of Visual Studio. Currently the scripts in contrib/cmake/msvc support 2005/8/10/12/13/15/17.

I've been away from home since late September to visit friends in the States and attend weddings in Scotland and Vietnam. While "on the road", I've been delighted by the contributions made by @piponazo , @D4N, @tbeu and others. Thank You, Gentlemen. I'm hoping to get "back up to speed" with Exiv2 in December. In particular, I'm looking forward to seeing conan fullfill its potential.

In the next few days, I'll review the current state of msvc, contrib/cmake/msvc, contrib/(autotools) and contrib/buildserver. I'm happy to maintain this elderly code because it works and has served for years. The time to decide to abandon those environments is when we are totally certain that the "new stuff" really does deliver. And I'm happy that new team members develop the CMake infrastructure and do not have to spend time this older build technology.

@mardy

This comment has been minimized.

Copy link
Author

mardy commented Dec 4, 2017

Hi Robin! Unfortunately I cannot remember the exact steps I took, and now that I look at the source code tree I realize that I probably didn't run any of the cmd scripts I see there. Instead, I believe that I opened the msvc/libexiv2/libexiv2.vcproj file with Visual Studio 2017, which took ages to update the file and then anyway failed to build it (I can't recall the reason).

Anyway, I'm sure that it was me who made something wrong :-) But the point of my report is that it would be nice if in the README-CMAKE file there was some kind of exact guidance about what method to use to build the project. Something like this (I'm just making up the text myself, just as an example):

  • If plan building your app with mingw, exiv2 must also be compiled with mingw. So, use the CMakeLists X with options A, B and C.
  • If you use MSVC also need to build zlib, then follow the instructions at Y.
  • If you use MSVC and have zlib already built, then use the CMakeLists.txt Z.

So that ideally, the user will not have to choose himself which path to take, but will always end up following the method that fits his needs.

Thanks for all your work with exiv2, it's a fantastic project :-)

@clanmills

This comment has been minimized.

Copy link
Collaborator

clanmills commented Dec 5, 2017

Thanks for your positive input. I've been off travelling for 2+ months and the msvc/ build has broken during my trip. I'll fix it in the next few days.

You are quite correct that we should give give better guidance on "how to build for this/n/that".

I'm hoping to get v0.27 RC1 released in 2017 and will review the various readme files. You're welcome of course to comment on my changes.

I'm going to leave this thread "open" to remind me to perform those reviews and updates. I'll let you know when they are available for comment.

@jasjuang

This comment has been minimized.

Copy link

jasjuang commented Dec 27, 2017

@mardy You can try building exiv2 with vcpkg. It will be as simple as vcpkg install exiv2

@piponazo

This comment has been minimized.

Copy link
Collaborator

piponazo commented Apr 9, 2018

Hi guys. Since I started to contribute in the project, my major aim has been to make CMake the main configuration system for Exiv2.

During some months I have been experimenting with conan for managing the few dependencies that this project has: libcurl, gtest, expat and zlib. Right now, we can use conan to bring those dependencies for the 3 main platforms: OSX, Linux and Windows. Thanks to conan we can also build them easily for different compilers (msvc, gcc, clang) and options. Actually, our CI checks (Travis and Appveyor) are already using conan for bringing those dependencies.

Even when we still have some users reporting things that could be improved in our CMake code, I am pretty confident that we could drop all the existing MSVC solutions and projects inside the msvc folder, and rely on CMake to auto-generate those ones (or even use other generators, such as Ninja).

If we decide to do that, we will update the README files accordingly. I also think that there is too much information right now in those files, and the variety of methods to compile the code, creates more confusion than it helps.

@clanmills

This comment has been minimized.

Copy link
Collaborator

clanmills commented Apr 9, 2018

Luis, you know I'm not going to agree to this without considerable evidence that this will work well. I haven't done the work to restore the msvc/ environment to working health. If we go down your proposed road, that will save me a chore.

At the moment, the only way in which I can build Exiv2/msvc is using contrib/cmake/msvc/cmakeBuild.cmd

I don't know how to get conan to build from the command line. So if you update the docs on how to build Exiv2/msvc (and its dependencies), I'll be happy to test the documentation.

@piponazo

This comment has been minimized.

Copy link
Collaborator

piponazo commented Apr 9, 2018

At the beginning I hesitated a bit about adding too much conan documentation here (since it can be found in their own page). However, now I think it will be useful to have a step-by-step guide so that anyone can learn how to use it, and compile with CMake in less than 5 minutes 😄 .

I will try to write that documentation in the next days.

@clanmills

This comment has been minimized.

Copy link
Collaborator

clanmills commented Apr 9, 2018

That's great. If you do that and it works for me, I'll remove the msvc/ directory.

For sure, with the contributions of you and Dan, we're able to undertake very desirable changes (C++11 and conan) which I've hitherto thought would be very difficult. For sure I put a lot of effort into contrib/cmake/msvc/cmakeBuild.cmd. I'll be happy to say goodnight to that.

For sure those changes have the consequence of removing support for elderly build systems such as Visual Studio 2005. It's unlikely that we'll get complaints about that. However when we publish Exiv2 v0.27 RC1, our major users such as darktable will speak up loudly if they can't build their product.

@clanmills

This comment has been minimized.

Copy link
Collaborator

clanmills commented Apr 9, 2018

Here's a conversation with Roman LebedevRI (darktable) about C++11 and Exiv2: #236 (comment)

I'm currently with with Roman (and others) to reverse engineering Canon's new CR3 format. I'll discuss our C++11 plans with him after the meeting in England and we are solid about our intentions.

I updated the issue concerning FindIconv.cmake. I've discovered an easy way to build libiconv for Visual Studio 2015 and 2017. Here's another reason to say that we should drop older versions of Visual Studio. I've supported 2005/8/10/12/13 in the past because there was almost no cost/effort involved. Time to move forward.

Your push and enthusiasm is well placed and appreciated.

@piponazo

This comment has been minimized.

Copy link
Collaborator

piponazo commented Apr 9, 2018

Note that CMake is able to generate solutions for Visual Studio 2005, these are the VS generators supported by CMake:

The following generators are available on this platform:
  Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Visual Studio 9 2008 [arch]  = Generates Visual Studio 2008 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Visual Studio 8 2005 [arch]  = Deprecated.  Generates Visual Studio 2005
                                 project files.  Optional [arch] can be
                                 "Win64".

I do not know if there are still available ISOs on the web for that version of the compiler. But once I write the instructions it would be interesting to check if our CMake code is still compatible with those old VS versions.

@clanmills

This comment has been minimized.

Copy link
Collaborator

clanmills commented Apr 9, 2018

Oh, sure. The published msvc builds of Exiv2 were built using those generators.

However, I think we now have code (such as C++11 and src/op_safe.hpp) which can't be compiled by those elderly versions of C++.

I hope we can retain an API which can be used by C++98 build systems. I'm OK about us using newer technology inside the library. If we avoid imposing C++11 on our users, that has value for them.

@piponazo piponazo added this to TODO in v0.27 May 7, 2018

@piponazo

This comment has been minimized.

Copy link
Collaborator

piponazo commented May 7, 2018

As we discussed in the Exiv2 team meeting, the plan would be to drop the support of autotools and the msvc projects/solutions in the 0.27 RC. I will do that once #297 is done.

@piponazo piponazo moved this from TODO to In Progress in v0.27 May 31, 2018

@piponazo piponazo self-assigned this May 31, 2018

@piponazo piponazo closed this in #338 Jun 8, 2018

@piponazo piponazo moved this from In Progress to Done in v0.27 Jun 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.