User:Callahanp/fg-from-scratch: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(→‎Notes: Package Cmake Compatablity with built-in CMake Targets.)
Line 44: Line 44:


The CMakeLists.txt used by the OpenSceneGraph, Simgear, FlightGear and TerraGear projects are used in automatic build processes and in the case of OSG are separately managed projects. They should be considered out of the scope of changes to fg-from-scratch.  Anyone working on fg-from-scratch will have to make do with their current state, adjust to any changes in them, and advocate separately for any proposed changes to them.
The CMakeLists.txt used by the OpenSceneGraph, Simgear, FlightGear and TerraGear projects are used in automatic build processes and in the case of OSG are separately managed projects. They should be considered out of the scope of changes to fg-from-scratch.  Anyone working on fg-from-scratch will have to make do with their current state, adjust to any changes in them, and advocate separately for any proposed changes to them.
==== Package CMake Compatability with Built-In CMake Targets ====
The log of a fg-from-scratch.cmd run includes the following text:
The package openssl is compatible with built-in CMake targets:
    find_package(OpenSSL REQUIRED)
    target_link_libraries(main PRIVATE OpenSSL::SSL OpenSSL::Crypto)
Does this imply that there are other packages which do not satisfy this criteria?  If so, which ones are not?  What is the impact of a package not being compatible with built in CMake targets?

Revision as of 15:20, 22 February 2020

fg-from-scratch is a windows batch script capable of producing a working release version of flightgear and terragear executables.

As soon as practical, replace this copy of your original e-mail with a link to the thread on the flightgear-developer's list.

I'm about to start working on a debug build, based on fg-from-scratch.cmd

As currently written, the script is fully capable of producing a release build for flightgear and terragear. Currently It leverages vcpkg, and cmake to produce the release executables. As part of its build it produces windows versions of all of the open-source libraries that underlie openscenegraph, simgear, flightgear and terragear. Starting with Cmake, it produces a visual studio project that can be used to rebuild the release version, but currently fails to produce a working debug version.

Before starting, in order to fully understand the existing fg-from-scratch, I'm doing a bit of reading on vcpkg, cmake and visual studio and examining the existing directory structure and files.

As for changes, there's no need to wait. I'll be watching for merge requests to the fg-meta/fg-from-scratch folder. Don't hold back...

I'll be doing a deep dive until I feel ready to propose specific changes to the existing script. If you want to work with me on this you can contact me through a reply to this thread. I have a phone, a gmail account (google hangouts) and an IRC client for real time communication. I'll be posting notes to

In the meantime, anyone with a sense of what needs doing is welcome to respond to this thread with suggestions or direction.


Cmake and Visual Studio

vcxpkg

ninja

Tasks:

  • Find out if ninja is currently used in fg-from-scratch.cmd
  • if it is include it in research.
  • If not, discuss advantages/disadvantages with the wider flightgear development community.

Per target build and install directories

A technique I've observed in use is to provide separate build and install directories for each target build: release, rel-with-debug, debug.

Task:

  • Investigate vcpkg-git, scratch-build and scratch-install to determine where per-target build or install directories are and are not used.

Notes

CMakeLists.txt in OpenSceneGraph, Simgear, FlightGear, SimGear

This note is not meant to imply that changes in the named projects Cmake files are or will be needed.

The CMakeLists.txt used by the OpenSceneGraph, Simgear, FlightGear and TerraGear projects are used in automatic build processes and in the case of OSG are separately managed projects. They should be considered out of the scope of changes to fg-from-scratch. Anyone working on fg-from-scratch will have to make do with their current state, adjust to any changes in them, and advocate separately for any proposed changes to them.

Package CMake Compatability with Built-In CMake Targets

The log of a fg-from-scratch.cmd run includes the following text:

The package openssl is compatible with built-in CMake targets:

   find_package(OpenSSL REQUIRED)
   target_link_libraries(main PRIVATE OpenSSL::SSL OpenSSL::Crypto)

Does this imply that there are other packages which do not satisfy this criteria? If so, which ones are not? What is the impact of a package not being compatible with built in CMake targets?