2017-02-27 10:07:52 +00:00
|
|
|
#
|
|
|
|
# This program source code file is part of KiCad, a free EDA CAD application.
|
|
|
|
#
|
|
|
|
# Copyright (C) 2017 CERN
|
|
|
|
# @author Alejandro García Montoro <alejandro.garciamontoro@gmail.com>
|
|
|
|
#
|
|
|
|
# This program is free software; you can redistribute it and/or
|
|
|
|
# modify it under the terms of the GNU General Public License
|
|
|
|
# as published by the Free Software Foundation; either version 2
|
|
|
|
# of the License, or (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program; if not, you may find one here:
|
|
|
|
# http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
|
|
|
|
# or you may search the http://www.gnu.org website for the version 2 license,
|
|
|
|
# or you may write to the Free Software Foundation, Inc.,
|
|
|
|
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
|
|
|
|
|
2019-01-09 14:35:42 +00:00
|
|
|
|
2017-02-27 10:07:52 +00:00
|
|
|
include_directories( BEFORE ${INC_BEFORE} )
|
|
|
|
|
2019-04-02 12:36:12 +00:00
|
|
|
add_executable( qa_eeschema
|
|
|
|
# A single top to load the pcnew kiface
|
|
|
|
# ../../common/single_top.cpp
|
2017-12-06 02:42:39 +00:00
|
|
|
|
2019-04-02 12:36:12 +00:00
|
|
|
# stuff from common which is needed...why?
|
2020-01-22 23:27:20 +00:00
|
|
|
${CMAKE_SOURCE_DIR}/common/colors.cpp
|
|
|
|
${CMAKE_SOURCE_DIR}/common/observable.cpp
|
2019-04-02 12:36:12 +00:00
|
|
|
|
2019-04-23 08:18:15 +00:00
|
|
|
# need the mock Pgm for many functions
|
|
|
|
mocks_eeschema.cpp
|
|
|
|
|
2019-04-02 15:35:25 +00:00
|
|
|
eeschema_test_utils.cpp
|
2020-02-28 21:55:51 +00:00
|
|
|
uuid_test_utils.cpp
|
2019-04-02 15:35:25 +00:00
|
|
|
|
2019-04-02 12:36:12 +00:00
|
|
|
# The main test entry points
|
|
|
|
test_module.cpp
|
|
|
|
|
2019-12-30 18:28:00 +00:00
|
|
|
# Base internal units (1=100nm) testing.
|
|
|
|
test_sch_biu.cpp
|
|
|
|
|
2019-04-02 12:36:12 +00:00
|
|
|
test_eagle_plugin.cpp
|
2020-03-10 15:04:05 +00:00
|
|
|
test_lib_arc.cpp
|
2019-04-23 08:18:15 +00:00
|
|
|
test_lib_part.cpp
|
|
|
|
test_sch_pin.cpp
|
2019-06-25 23:39:58 +00:00
|
|
|
test_sch_rtree.cpp
|
2019-04-23 08:18:15 +00:00
|
|
|
test_sch_sheet.cpp
|
|
|
|
test_sch_sheet_path.cpp
|
2020-04-15 01:51:58 +00:00
|
|
|
|
|
|
|
# Simulation tests
|
|
|
|
sim/test_netlist_exporter_pspice_sim.cpp
|
Eeschema: build with object libraries
This is done to allow access to the eeschema library
internals for purposes of test and script access, as the
DLL library has highly restrictive -fvisibility settings
that otherwise prevent the tests being able to access 99.9%
of the eeschema library functions (only a single function
is APIEXPORT'ed, therefore that's the only test we can do).
Using object libraries is a bit of a hack, and makes for
a slower link when done for multiple targets, but with the currently
supported CMake versions, it's about as good as we can get.
A better solution in the longer term may be to break eeschema_kiface(_objects)
into many smaller libraries, each of which has a much more defined scope,
rather than one big interlinked amorphous lump. This has the advantage that
each module is testable in isolation, and we get better organisation of
inter-dependencies in the codebase.
Then, the kiface DLL will gather these sub-libs and present what
is needed on the visible DLL API. Thus, we get both a testable
suite of library functions, and a restricted kiface DLL interface.
2019-04-23 07:58:17 +00:00
|
|
|
|
|
|
|
# Older CMakes cannot link OBJECT libraries
|
|
|
|
# https://cmake.org/pipermail/cmake/2013-November/056263.html
|
|
|
|
$<TARGET_OBJECTS:eeschema_kiface_objects>
|
2019-04-02 12:36:12 +00:00
|
|
|
)
|
|
|
|
|
2019-06-23 19:49:13 +00:00
|
|
|
# Anytime we link to the kiface_objects, we have to add a dependency on the last object
|
|
|
|
# to ensure that the generated lexer files are finished being used before the qa runs in a
|
|
|
|
# multi-threaded build
|
|
|
|
add_dependencies( qa_eeschema eeschema )
|
|
|
|
|
2019-04-02 12:36:12 +00:00
|
|
|
target_link_libraries( qa_eeschema
|
|
|
|
common
|
2020-03-10 15:04:05 +00:00
|
|
|
kimath
|
2019-04-02 12:36:12 +00:00
|
|
|
qa_utils
|
|
|
|
unit_test_utils
|
2019-12-29 13:07:17 +00:00
|
|
|
markdown_lib
|
2019-04-02 12:36:12 +00:00
|
|
|
${GDI_PLUS_LIBRARIES}
|
|
|
|
${Boost_LIBRARIES}
|
|
|
|
)
|
|
|
|
|
Eeschema: build with object libraries
This is done to allow access to the eeschema library
internals for purposes of test and script access, as the
DLL library has highly restrictive -fvisibility settings
that otherwise prevent the tests being able to access 99.9%
of the eeschema library functions (only a single function
is APIEXPORT'ed, therefore that's the only test we can do).
Using object libraries is a bit of a hack, and makes for
a slower link when done for multiple targets, but with the currently
supported CMake versions, it's about as good as we can get.
A better solution in the longer term may be to break eeschema_kiface(_objects)
into many smaller libraries, each of which has a much more defined scope,
rather than one big interlinked amorphous lump. This has the advantage that
each module is testable in isolation, and we get better organisation of
inter-dependencies in the codebase.
Then, the kiface DLL will gather these sub-libs and present what
is needed on the visible DLL API. Thus, we get both a testable
suite of library functions, and a restricted kiface DLL interface.
2019-04-23 07:58:17 +00:00
|
|
|
target_include_directories( qa_eeschema PUBLIC
|
|
|
|
# Paths for eeschema lib usage (should really be in eeschema/common
|
|
|
|
# target_include_directories and made PUBLIC)
|
2019-07-03 09:08:55 +00:00
|
|
|
$<TARGET_PROPERTY:eeschema_kiface_objects,INCLUDE_DIRECTORIES>
|
Eeschema: build with object libraries
This is done to allow access to the eeschema library
internals for purposes of test and script access, as the
DLL library has highly restrictive -fvisibility settings
that otherwise prevent the tests being able to access 99.9%
of the eeschema library functions (only a single function
is APIEXPORT'ed, therefore that's the only test we can do).
Using object libraries is a bit of a hack, and makes for
a slower link when done for multiple targets, but with the currently
supported CMake versions, it's about as good as we can get.
A better solution in the longer term may be to break eeschema_kiface(_objects)
into many smaller libraries, each of which has a much more defined scope,
rather than one big interlinked amorphous lump. This has the advantage that
each module is testable in isolation, and we get better organisation of
inter-dependencies in the codebase.
Then, the kiface DLL will gather these sub-libs and present what
is needed on the visible DLL API. Thus, we get both a testable
suite of library functions, and a restricted kiface DLL interface.
2019-04-23 07:58:17 +00:00
|
|
|
)
|
|
|
|
|
2019-04-02 12:36:12 +00:00
|
|
|
# Eeschema tests, so pretend to be eeschema (for units, etc)
|
|
|
|
target_compile_definitions( qa_eeschema
|
|
|
|
PUBLIC EESCHEMA
|
2019-04-02 15:35:25 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
# Pass in the default data location
|
|
|
|
set_source_files_properties( eeschema_test_utils.cpp PROPERTIES
|
|
|
|
COMPILE_DEFINITIONS "QA_EESCHEMA_DATA_LOCATION=(\"${CMAKE_CURRENT_SOURCE_DIR}/data\")"
|
2019-04-17 11:41:15 +00:00
|
|
|
)
|
|
|
|
|
2019-07-03 09:08:55 +00:00
|
|
|
kicad_add_boost_test( qa_eeschema eeschema )
|