| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since now extra options via dh command line arguments are encouraged, dh will
break when a bit more complex option gets added to DH_INTERNAL_OPTIONS and it
gets misparsed by the debhelper command called from the override. E.g.
debian/rules:
| %:
| dh --builddirectory="build dir"
|
| override_dh_install:
| dh_install
Will fail with something like:
| ....
| make[1]: Entering directory `............'
| dh_install
| cp: cannot stat `debian/tmp/dir': No such file or directory
| dh_install: cp returned exit code 1
| make[1]: *** [override_dh_install] Error 1
So since DH_INTERNAL_OPTIONS is exclusively for internal use, why not to use an
old good ASCII unrepresentable control character as a separator? So I chose
ASCII 1E - RS Record Separator.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
| |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
|
|
|
|
| |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
| |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
|
|
|
|
| |
If build directory is absolute or ../ path, _rel2rel falls back to
absolute paths. Try even harder to convert supplied builddir to
relative in _set_builddir().
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
| |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
|
|
|
|
| |
Also add enforce_out_of_source_building() for clarity which does not
take any parameters. Now both have a clear name and no confusing
parameter combinations.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
|
| |
and further suppress warnings about such options it passes on to debhelper
commands. This was attempted incompletely before in version 7.2.17.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Move two move command-specific options to only be accepted by the commands
that use them. The options are:
--sourcedir, --destdir
* If any third-party debhelper commands use either of the above options,
they will be broken, and need to be changed to pass options to init().
This was done because of a conflict with the --sourcedirectory options
used by dh_auto_*. I originally wanted to make dh_auto_* and dh_install
both use --sourcedir, but that didn't work out.
|
|\
| |
| |
| |
| | |
Conflicts:
dh_auto_install
|
| |
| |
| |
| |
| |
| |
| | |
I'm unsure why we need this complication. Perl modules are allowed to
install man pages documenting the module, if it really needs documentation.
This reverts commit 49b64c7852744f54250121b1c60544e1f5de70b6.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I'm reverting the documentation addition to try doing it
myself, more simply and less verbosely.
This reverts commit 962a2e10c930e3504ea1c0327be2fdf70d53023e.
Conflicts:
dh_auto.pod
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
I previously used "built-in debhelper build system" or "default debhelper build
system" for those shipped with debhelper. Now it is "standard debhelper build
system".
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| | |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* dh_auto.pod -> dh_auto.7 - contains general information about dh_auto,
its features, build systems supported by default (the latter is injected by
man/dh_auto_pod script from Debian/Debhelper/Buildsystem/*.pm PODs via
placeholders (#PLACEHOLDER#))
* POD in Debian/Debhelper/Buildsystem/*.pm -> dh_auto_<buildsystem>.7 - build
system specific information.
* dh_auto_* -> dh_auto_*.1 - relatively shorty description of the specific
dh_auto_* program and build system specific info for that step injected from
Debian/Debhelper/Buildsystem/*.pm with man/dh_auto_pod script.
* man/dh_auto_pod $step - generates full dh_auto_$step POD (replaces
placeholders).
* man/dh_auto_pod - generates full dh_auto.pod (replaces placeholders).
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| | |
Apparently, cmake itself reads values of those environment variables and uses
them accordingly. There is no need to repass them via -DCMAKE_{C,CXX,LD}_FLAGS.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| | |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| | |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| |
| | |
* buildsystem -> build system
* dh_auto build system -> debhelper build system
* plugin -> class
* a few rewording changes in the comments.
* Enhance python_distutils::DESCRIPTION().
|
| |
| |
| |
| |
| |
| |
| |
| | |
Displays POD of the (auto)selected build system. It should be useful to get
more information about third party build systems. Implementation uses
perldoc whenever possible.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| | |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Apparently, Distutils does out of source tree building by default.
* Default build directory is "$srcdir/build".
* --build-base command line option is ineffective (some even fail)
unless it is passed to the "build" command. However, if build-base is set in
the config file, all setup.py commands use it (build, install and clean).
That's a big flaw in Distutils design but it has been like this for a long
time. Therefore write a custom distutils cfg file in the build directory
to make build-base work. The best choice for config file path is
$HOME/.pydistutils.cfg (one of the paths Distutils reads) and setting $HOME
to the build directory.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| | |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| | |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* New short switches:
-D = --sourcedirectory
-B = --builddirectory
-S = --buildsystem
* Drop DH_AUTO_BUILD* environment variables (reintroduced due to revert).
* Adjust test suite.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This mostly reverts commit f897611a77726655aea258af0c4d52a8ce759ebc.
Remaining cosmetic changes (all functional changes have been reverted):
* Refactoring of option string into split_options_string() sub (no semantic
changes though).
* Cosmetic change in Dh_Buildsystems.pm.
Breaks testsuite.
|
| |
| |
| |
| |
| |
| |
| | |
Previous one caused test "_rel2rel no4" to fail. Also add a new test
for _canonpath and two new tests for _rel2rel (related to "." handling).
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Technically, cmake supports in source builds, they are simply not
recommended. However, if the user insists and explicitly specifies
the build directory that is equal to the source directory, allow
this (aka soft mode).
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now build directory is always relative to the top directory
(including default build directory) regardless what source
directory is. However, if the build directory is not specified,
it defaults to the source directory (aka in source building).
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
Debian/Debhelper/Dh_Getopt.pm
debian/changelog
|
| |
| |
| |
| | |
causing other commands to emit a getopt warning or deprecation message.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Whenever make is run with --print-directory option, make -C sometimes print
Entering/Leaving directory messages to stdout even with -s in effects This
breakes a check for target existance as it relies on make printing nothing when
target does not do anything. Hence explicitly pass --no-print-directory to make
to avoid it.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| |
| | |
* Reorder $system and $step arguments to match create_buildsystem_instance()
order (less confusion).
* Pass arbitrary @_ from load_buildsystem() to create_buildsystem_instance().
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is backwards compatible (with << 7.3) until build, test and clean steps
are not reimplemented in the backwards compatibility breaking way. However,
this is absolutely necessary for enforce_in_source_building() to work in corner
cases (when build directory is set) in build, test and clean steps as the next
class (makefile) does not enforce it. makefile will fail as it will look for
Makefile in the build directory rather than the source directory.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Auto-setting is_buildable flag in base constructor was pointless
and broken by design because:
- is_buildable = check_auto_buildable() used to be called *before*
constructor of the derivative class could call enforce_* methods. The
result of check_auto_buildable() might change after calling enforce_*
methods (in case check_auto_buildable() use get_buildpath() tests).
- it isn't used widely. Refactor those a few places.
* Due to above, 'build_step' does not need to be passed to the Buildsystem
anymore. Remove it from code.
* As a result of is_buidable removal, move warning of
enforce_in_source_building() to pre_building_step(). It caused unnecessary
noise when the object was constructed during test. It belongs to
pre_building_step stage anyway.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Move setting of new build directory from constructor to _set_builddir()
method including detection if directory (current or source) it should be
relative to.
* Even if a new build directory was specified, detect if it matches the source
directory and unset it in such a case.
* Use _set_builddir() in enforce_out_of_source_tree() methods. Previous
implementation didn't handle default build directory properly (i.e.
relativeness to current or source directory).
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| |
| |
| |
| | |
When rmdir_building(), if build directory has 2 or more levels,
empty parent dirs should also be deleted until source directory level.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
| |
| |
| | |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
* New optional option --sourcedirectory/-d.
* New Buildsystem API methods for getting source directory/path
(since sourcedir may no longer be topdir), source 2 build
directory convertions, doit_in_sourcedir() etc.
* clean_builddir() -> rmdir_builddir() rename.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Implement a new sub in Dh_Buildsystems (load_all_buildsystems()) which
dynamically tries to find all buildsystem class files in perl module
directories (@INC) and clearly marks third party buildsystems as such.
* Use this sub for listing buildsystems so now --list easily helps a user
discover *all* buildsystem classes installed on his/her system clearly
separating built-in ones from third party ones.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* DH_AUTO_OPTIONS is like existing DH_OPTIONS, just only for dh_auto
stuff. This also avoids "explosion" of separate DH_AUTO_* environment
variables (i.e. exports in debian/rules) and encourages usage of dh_auto
command line option names. DH_AUTO_OPTIONS is passed via "extra_args" to
Dh_Lib::init() (API addition).
* When splitting options from DH_OPTIONS and its flavours, allow arguments
to include whitespaces if they are escaped with backslash (\) (see
split_options_string()). Document this in debhelper.pod.
* Short option for --buildsystem is -c (aka class).
* Provide API to cancel option specs from default debhelper options.
It will be used in the feature.
|
| |
| |
| |
| |
| |
| | |
* "out of source" or "out of source tree" seems to be more popular
term to describe building in the builddir.
* Avoid using hyphens in both "out of source" and "in source" terms.
|
| |
| |
| |
| |
| | |
I'm going to use this new term in documentation. I have never liked "action"
in this context, just couldn't think of anything better.
|
|\| |
|