Installer must be run as administrator

[LegalizeAdulthood]

When attempting to run the installer, it tells me that it cannot install to C:\Program Files\DoxyPress without telling my why it can't install there. I know enough about installers to guess that this is an elevation problem, so I run the installer as administrator and it works properly. This shouldn't be required. I don't know where your installer source is located but for Windows you should consider using WiX to get things done properly and avoid non-standard experience like this.

[LegalizeAdulthood]

Oh, looks like you're using CPACK. There is a WiX template for CPACK.

[agserm]

We are not using CPACK, and the CMake build for DoxyPress is still a work in progress. The vendor of the installer software had a new release this month, we will check and see if there is now a better way to handle elevation of the installer.

[bgeller]

I found an option in the installer program to request administrator rights . I will set this option accordingly for the next release. Thank you for bringing this issue to our attention.

[LegalizeAdulthood]

Ah, your CMake build is a work in progress. It does have some CPACK properties set inside there. I would recommend finishing the switch to a CMake build away from autotools and use the WiX CPACK template. Finishing the CMake switch shouldn't be too hard from my skimming of your project; do you need help with it?

[bgeller]

Our goal is to support building DoxyPress from both Autotools and CMake. We appreciate any input or contributions to the CMake build system.

The main problem we need to solve is how to locate the installed copy of CopperSpice. The CMake files need to locate CS when:

a) CS was built with CMake b) CS was built with Autotools c) CS was installed from a binary distribution

The other issue we are reviewing is how to specify the CS libraries with the format of "CopperSpice::Core" instead of the full path and dll extension. Obviously this needs to work properly on linux and windows.

Thanks for anything you can do to help out.

[LegalizeAdulthood]

Maintaining two build systems is a source of future errors since people need to make two edits instead of one in order to have changes incorporated.

I can understand this as a temporary situation while you transition from one to another, but why do you wish to keep both build systems going in perpetuity?

[bgeller]

Although CMake has a good following so does Autotools. We have seen countless arguments for both systems and from everything we have read there is no clear choice. We are aware of the requirement to maintain both systems. As developers contribute to this project we may need to update one of the the build systems to support a commit. We will continue to review this option as time goes on.

[LegalizeAdulthood]

My two cents:

• autotools doesn't play well with non-unix systems (which is more than just Windows, although that is the primary non-unix environment used these days)
• autotools only generates Makefiles
• CMake can generate IDE projects for all the major IDEs
• CMake can target ninja builds for builds faster than make
• The author of the book on autotools (John Calcote), agrees with the criticism of autotools made by the authors of the book on CMake (KitWare). I worked with John at Fusion-io and asked him this specifically.
• CMake continues to gain traction among projects
• CMake overtook autotools in google search queries around 2006 and overtook autotools in ohloh around 2010 (Source: Building Science with CMake, Google Tech Talk Oct 21, 2015)
• AutoTools are difficult to use and learn
• CMake is easy to use and learn
• My personal observation is that new projects use CMake and only use autotools if
  • it's all the authors know, or
  • the authors intentionally only care about linux and poo-poo Windows and they know autotools will be a barrier to their code being used in Windows.
• My Utah C++ User Group presentation on CMake was one of the most heavily attended presentations in our history. I doubt if I'd had gotten the same attendance had I done a presentation on autotools.
• A number of people are building a package management system on top of CMake (e.g. Hunter). While there is a flurry of package manager activity out there in the C++ community, none of them are based on, or use, autotools AFAIK.

All of this is just why I think CMake is the way to go, but in no way am I trying to tell you what to do with doxypress.

[agserm]

I can raise just as many issues and problems with CMake, but that is not the point. As Barbara explained, we are currently supporting both. If you wish to assist us with the CMake build system, we certainly appreciate your support.