ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/SConstruct

80 lines
2.3 KiB
Python
Raw Normal View History

Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
# coding: utf-8
SCons driven build system: Skeleton To find out if SCons is suitable for Cinelerra's build system, I'll try to write a protorype, including platform configuration support, installing and support for packaging.
2007-06-30 04:41:52 +02:00
##
Remove Debian/Lenny workarounds definitively requiring Squeeze now
2011-12-03 01:56:30 +01:00
## SConstruct - SCons based build-system for Lumiera
SCons driven build system: Skeleton To find out if SCons is suitable for Cinelerra's build system, I'll try to write a protorype, including platform configuration support, installing and support for packaging.
2007-06-30 04:41:52 +02:00
##
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
# Copyright (C)
Build: some further code clean-up and documentation * Simplify some constructs from the Python-3 migration * update copyright, since I did maintain the SCons build continuosly * remove unused method from Buildhelper Furthermore, the documentation page for our build system https://lumiera.org/documentation/technical/build/SCons.html has been reworked, to add a synopsis, some further background information about the internal structure of SCons and about the specific conventions and definitions used for Lumiera
2025-11-25 02:14:21 +01:00
# 2008-2025 Hermann Vosseler <Ichthyostega@web.de>
SCons driven build system: Skeleton To find out if SCons is suitable for Cinelerra's build system, I'll try to write a protorype, including platform configuration support, installing and support for packaging.
2007-06-30 04:41:52 +02:00
#
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
# **Lumiera** 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. See the file COPYING for further details.
SCons driven build system: Skeleton To find out if SCons is suitable for Cinelerra's build system, I'll try to write a protorype, including platform configuration support, installing and support for packaging.
2007-06-30 04:41:52 +02:00
#####################################################################
SCons: finish reworking buildsystem to rely on custom builders. All target paths and install targets now defined automatically, most of the buildscript just using plain sourcefile names
2011-01-30 22:12:55 +01:00
# NOTE: scons -h for help.
clean up top level SConstruct
2012-01-10 08:37:01 +01:00
# This script /defines/ the components and how they fit together.
# SCons will derive dependencies and the necessary build steps.
Build: some further code clean-up and documentation * Simplify some constructs from the Python-3 migration * update copyright, since I did maintain the SCons build continuosly * remove unused method from Buildhelper Furthermore, the documentation page for our build system https://lumiera.org/documentation/technical/build/SCons.html has been reworked, to add a synopsis, some further background information about the internal structure of SCons and about the specific conventions and definitions used for Lumiera
2025-11-25 02:14:21 +01:00
# Read more about the SCons build system at: https://www.scons.org
SCons: finish reworking buildsystem to rely on custom builders. All target paths and install targets now defined automatically, most of the buildscript just using plain sourcefile names
2011-01-30 22:12:55 +01:00
Global-Layer-Renaming: fix handling of GuiResources in the build the new structure causes them now to be installed into $TARGET/stage which is simply not what I want. I still consider $TARGET/gui the better choice, since an administrator or packager is not aware of our layer namings. The existing solution was half baked anyway, it did not really replicate the source tree. On the other hand, I want to retain the location of the CSS files within the GUI tree, since I consider it a good practice, to keep "code-like" resources with the actual code, and not far away in some arcane "data" directory. No I've noticed, that the env.GuiResource() function is only used once, for this very task. So, for the time being, we can keep it simple and deditaced to that task, i.e we pick up all CSS files we find and install it into a single target directory. NOTE: this issue has brought to my attention two further, completely unrelated issues * Ticket #1192 (Lumiera hangs on failed GUI start) * The ProcDispatcher does an idle wait, due to an error in timed-wait implementation
2018-11-16 18:18:33 +01:00
# NOTE: Lumiera SCons extension modules and plugins
#--------------------------------------------------
replace the homebrew GCH-builder by a lib solution
2008-08-21 09:59:24 +02:00
import sys
clean up top level SConstruct
2012-01-10 08:37:01 +01:00
sys.path.append('./admin/scons')
Global-Layer-Renaming: fix handling of GuiResources in the build the new structure causes them now to be installed into $TARGET/stage which is simply not what I want. I still consider $TARGET/gui the better choice, since an administrator or packager is not aware of our layer namings. The existing solution was half baked anyway, it did not really replicate the source tree. On the other hand, I want to retain the location of the CSS files within the GUI tree, since I consider it a good practice, to keep "code-like" resources with the actual code, and not far away in some arcane "data" directory. No I've noticed, that the env.GuiResource() function is only used once, for this very task. So, for the time being, we can keep it simple and deditaced to that task, i.e we pick up all CSS files we find and install it into a single target directory. NOTE: this issue has brought to my attention two further, completely unrelated issues * Ticket #1192 (Lumiera hangs on failed GUI start) * The ProcDispatcher does an idle wait, due to an error in timed-wait implementation
2018-11-16 18:18:33 +01:00
#--------------------------------------------------
replace the homebrew GCH-builder by a lib solution
2008-08-21 09:59:24 +02:00
SCons driven build system: Skeleton To find out if SCons is suitable for Cinelerra's build system, I'll try to write a protorype, including platform configuration support, installing and support for packaging.
2007-06-30 04:41:52 +02:00
Move parts from main SConstruct into dedicated Python modules
2012-01-09 04:10:00 +01:00
import Setup
import Options
import Platform
Buildsystem: generate a compilation database for clangd (closes: #1436) Knowledge-Technology(Claude Opus 5) used - to assess the situation and present implementation avenues - for discussion while shaping the solution - for generating code and validating results Clang based tooling is used frequently for code analysis and navigation. This requires however that the exact flags and invocation is captured for each possible translation unit in the code base. That knowledge exists solely in the build system, and the established way to hand it over is the LLVM "JSON Compilation Database". SCons has provided a `CompilationDatabase` builder since 4.0, and it fits our setup well: it installs an emitter on the object builders and captures each command line while the dependency graph is constructed. Hence nothing is compiled -- generating takes about two seconds -- and the result always describes the complete build graph as declared, rather than the target actually requested on this invocation. This feature is provided as ''opt-in'', either through the sticky option `COMPILEDB=yes` or by direct invocation with `scons compiledb` The `compile_commands.json` is generated into the build output `target/' dir For configuration, a `.clangd` in project root instructs the language server where to find this file. __Note__ the ordering constraint recorded in `CompileDB.py`: the emitter must be installed only after `Platform.configure()` has run, or it also captures the `conftest_*` compilations of the configure checks. That is why this is a plain helper invoked from the `SConstruct` -- similar to Setup, Options, Platform -- and not a tool loaded from the `LumieraEnvironment`.
2026-10-01 23:22:36 +02:00
import CompileDB
Move parts from main SConstruct into dedicated Python modules
2012-01-09 04:10:00 +01:00
clean up top level SConstruct
2012-01-10 08:37:01 +01:00
from Buildhelper import *
from LumieraEnvironment import *
implemented additional functions like creating a tarball
2007-07-02 11:38:46 +02:00
actually switch to using those extracted modules from main build
2012-01-09 04:58:21 +01:00
#####################################################################
SCons driven build system: Skeleton To find out if SCons is suitable for Cinelerra's build system, I'll try to write a protorype, including platform configuration support, installing and support for packaging.
2007-06-30 04:41:52 +02:00
clean up top level SConstruct
2012-01-10 08:37:01 +01:00
env = Setup.defineBuildEnvironment() # dirs & compiler flags
env = Platform.configure(env) # library dependencies
Buildsystem: generate a compilation database for clangd (closes: #1436) Knowledge-Technology(Claude Opus 5) used - to assess the situation and present implementation avenues - for discussion while shaping the solution - for generating code and validating results Clang based tooling is used frequently for code analysis and navigation. This requires however that the exact flags and invocation is captured for each possible translation unit in the code base. That knowledge exists solely in the build system, and the established way to hand it over is the LLVM "JSON Compilation Database". SCons has provided a `CompilationDatabase` builder since 4.0, and it fits our setup well: it installs an emitter on the object builders and captures each command line while the dependency graph is constructed. Hence nothing is compiled -- generating takes about two seconds -- and the result always describes the complete build graph as declared, rather than the target actually requested on this invocation. This feature is provided as ''opt-in'', either through the sticky option `COMPILEDB=yes` or by direct invocation with `scons compiledb` The `compile_commands.json` is generated into the build output `target/' dir For configuration, a `.clangd` in project root instructs the language server where to find this file. __Note__ the ordering constraint recorded in `CompileDB.py`: the emitter must be installed only after `Platform.configure()` has run, or it also captures the `conftest_*` compilations of the configure checks. That is why this is a plain helper invoked from the `SConstruct` -- similar to Setup, Options, Platform -- and not a tool loaded from the `LumieraEnvironment`.
2026-10-01 23:22:36 +02:00
compileDB = CompileDB.setup(env) # code intelligence (opt-in: COMPILEDB=yes)
SCons driven build system: Skeleton To find out if SCons is suitable for Cinelerra's build system, I'll try to write a protorype, including platform configuration support, installing and support for packaging.
2007-06-30 04:41:52 +02:00
integrate Doxygen into SCons build. some doc fixes
2007-08-24 16:41:16 +02:00
finished basic implementation of SCons build system
2007-07-02 05:27:20 +02:00
SConstruct: reduce the remaining defs no need to use functions anymore, since only the clean and phony targets are left
2012-01-09 05:13:15 +01:00
### === MAIN BUILD === ##############################################
clean up top level SConstruct
2012-01-10 08:37:01 +01:00
# call subdir SConscript(s) to define the actual build targets...
create separate SConscript for documentation currently just featuring Doxygen
2012-01-10 08:21:27 +01:00
SConscript(dirs=['data','src','src/tool','research','tests','doc'], exports='env')
SConstruct: reduce the remaining defs no need to use functions anymore, since only the clean and phony targets are left
2012-01-09 05:13:15 +01:00
SCons driven build system: Skeleton To find out if SCons is suitable for Cinelerra's build system, I'll try to write a protorype, including platform configuration support, installing and support for packaging.
2007-06-30 04:41:52 +02:00
SConstruct: reduce the remaining defs no need to use functions anymore, since only the clean and phony targets are left
2012-01-09 05:13:15 +01:00
# additional files to be cleaned when cleaning 'build'
env.Clean ('build', [ 'scache.conf', '.sconf_temp', '.sconsign.dblite', 'config.log' ])
### === Alias Targets === ###########################################
clean up top level SConstruct
2012-01-10 08:37:01 +01:00
# pick up the targets defined by the sub SConscripts
Upgrade: disable doxygen builder (WIP) BuilderDoxygen and BuilderGCH are external plug-ins, not developed in this project and probably unmaintained. TODO: decide how to fix or replace them...
2023-08-07 23:42:57 +02:00
#Import('lumiera plugins tools gui testsuite doxydoc')
Import('lumiera plugins tools gui testsuite')
clean up top level SConstruct
2012-01-10 08:37:01 +01:00
Buildsystem: generate a compilation database for clangd (closes: #1436) Knowledge-Technology(Claude Opus 5) used - to assess the situation and present implementation avenues - for discussion while shaping the solution - for generating code and validating results Clang based tooling is used frequently for code analysis and navigation. This requires however that the exact flags and invocation is captured for each possible translation unit in the code base. That knowledge exists solely in the build system, and the established way to hand it over is the LLVM "JSON Compilation Database". SCons has provided a `CompilationDatabase` builder since 4.0, and it fits our setup well: it installs an emitter on the object builders and captures each command line while the dependency graph is constructed. Hence nothing is compiled -- generating takes about two seconds -- and the result always describes the complete build graph as declared, rather than the target actually requested on this invocation. This feature is provided as ''opt-in'', either through the sticky option `COMPILEDB=yes` or by direct invocation with `scons compiledb` The `compile_commands.json` is generated into the build output `target/' dir For configuration, a `.clangd` in project root instructs the language server where to find this file. __Note__ the ordering constraint recorded in `CompileDB.py`: the emitter must be installed only after `Platform.configure()` has run, or it also captures the `conftest_*` compilations of the configure checks. That is why this is a plain helper invoked from the `SConstruct` -- similar to Setup, Options, Platform -- and not a tool loaded from the `LumieraEnvironment`.
2026-10-01 23:22:36 +02:00
build = env.Alias('build', lumiera + plugins + tools + gui + compileDB)
Build: some further code clean-up and documentation * Simplify some constructs from the Python-3 migration * update copyright, since I did maintain the SCons build continuosly * remove unused method from Buildhelper Furthermore, the documentation page for our build system https://lumiera.org/documentation/technical/build/SCons.html has been reworked, to add a synopsis, some further background information about the internal structure of SCons and about the specific conventions and definitions used for Lumiera
2025-11-25 02:14:21 +01:00
# this defines the SCons **default target**
clean up top level SConstruct
2012-01-10 08:37:01 +01:00
env.Default('build')
SConstruct: reduce the remaining defs no need to use functions anymore, since only the clean and phony targets are left
2012-01-09 05:13:15 +01:00
create separate SConscript for documentation currently just featuring Doxygen
2012-01-10 08:21:27 +01:00
Upgrade: disable doxygen builder (WIP) BuilderDoxygen and BuilderGCH are external plug-ins, not developed in this project and probably unmaintained. TODO: decide how to fix or replace them...
2023-08-07 23:42:57 +02:00
#env.Alias ('all', build + testsuite + doxydoc)
env.Alias ('all', build + testsuite)
#env.Alias ('doc', doxydoc)
Add 'none' target to scons 'scons none' will not build anythinf but runs the configuration checks to determine if the system and libraries are sane to build Lumiera, this will be used in builddrone later.
2012-08-25 13:23:41 +02:00
env.Alias ('none')
SConstruct: reduce the remaining defs no need to use functions anymore, since only the clean and phony targets are left
2012-01-09 05:13:15 +01:00
env.Alias('install', gui)
env.Alias('install', '$DESTDIR')
#####################################################################
Reference in a new issue Copy permalink