How to change the default directory structure of dh_make so that dpkg-buildpackage does not throw any errors - postgresql

I am trying to create a debian package for a postgreSQL extension Apache-age release 1.1.1 and created the directory structure using dh_make command.
The directory structure is as follows:
age-1.1.1 (project root)
├── debian
│   ├── changelog
│   ├── compat
│   ├── control
│   ├── docs
│   ├── examples
│   ├── links
│   ├── manpages
│   ├── menu
│   ├── postinst
│   ├── postrm
│   ├── preinst
│   ├── prerm
│   ├── rules
│   ├── source
│   └── watch
├── src
└── Makefile
The dpkg-buildpackage -b when run from project-root folder it looks for debian folder, then reads the rule file, then reads the Makefile located in the project root to build the package.
I want to change the directory structure to the following:
.project root
├── packaging
│ ├── debian
│ │ ├── control
│ │ ├── control.in
│ │ ├── changelog
│ │ ├── copyright
│ │ ├── pgversions
│ │ ├── rules
│ │ └── ...
│ └──
├── src
├── LICENSE
├── README.md
├── Makefile
└── ...
I want to change the directory structure so that the dpkg-buildpackage -b command can be run from the packaging folder and it should build the package.

Inside your Makefile
Modify the install paths accordingly. It should point to your packaging/debian/* where * is the filename.
This way the Makefile can point to the correct file path target inside the new folder structure.

I'm not sure if this is the best way to do this but it's working for me:
Here are the steps:
First run the dh_make_pgxs command from the project root directory.
Create a packaging directory in the project root and move the debian directory created in step 1 to this directory along with the Makefile, age.control and the age--1.1.1.sql.
Your file structure should look like this:
.project root
├── packaging
│   ├── debian
│   │   ├── control
│   │   ├── control.in
│   │   ├── changelog
│   │   ├── copyright
│   │   ├── pgversions
│   │   ├── rules
│   │   └── ...
│   ├── age--1.1.1.sql
│   ├── age.control
│   ├── Makefile
│   └── ...
├── src
├── LICENSE
├── README.md
└── ...
Change the file paths in the Makefile like:
src/backend/age.o should be ../src/backend/age.o.
./tools/ should be ./../tools/.
and so on.
Now you can simply run the dpkg-buildpackage -b command from the packaging directory to build the debian package.
Note: In step 1 we are running dh_make_pgxs in the project root first, this is to make sure that the project name in the control files and the version in the changelog file are correct. In this case the name/source in control, control.in & changelog files should be apache-age and the version number in changelog file should be 1.1.1-1.
Alternatively, you can run the command from the packaging directory and manually change the name and version in the control and changelog files.

Related

Using GitHub Actions in a Single Repository with Multiple Projects

I am fairly competent in using GitHub actions to build a variety of languages, orchestrate deployments, and I've even done cross-repository actions using web-hooks, so I'd say that I'm pretty familiar with working with them.
I often find myself doing a lot of scratch projects to test out an API or making a demo, and these don't usually merit their own repositories, but I'd like to save them for posterity, rather than just making Gists out of them, Gists being largely impossible to search. I'd like to create a scratch repository, with folders per language, like:
.
└── scratch
├── go
│   ├── dancing
│   │   ├── LICENSE-APACHE
│   │   ├── LICENSE-MIT
│   │   ├── main.go
│   │   └── README.md
│   ├── gogettur
│   │   ├── LICENSE-APACHE
│   │   ├── LICENSE-MIT
│   │   ├── main.go
│   │   └── README.md
│   └── streeper
│   ├── LICENSE-APACHE
│   ├── LICENSE-MIT
│   ├── main.go
│   └── README.md
├── node
│   └── javawhat
│   ├── index.js
│   ├── LICENSE-APACHE
│   ├── LICENSE-MIT
│   └── README.md
└── rust
├── logvalanche
│   ├── Cargo.toml
│   ├── LICENSE-APACHE
│   ├── LICENSE-MIT
│   ├── README.md
│   └── src
├── streamini
│   ├── Cargo.toml
│   ├── LICENSE-APACHE
│   ├── LICENSE-MIT
│   ├── README.md
│   └── src
└── zcini
├── Cargo.toml
├── LICENSE-APACHE
├── LICENSE-MIT
├── README.md
└── src
I'd like to generalize GitHub actions per language, for Go, use go test ./... and go build, for Rust cargo test and cargo build, etc.
I know that what I could do is have a workflow for each created project, but this would be tedious, I'd end up copying and pasting most of the time, and every build would run on every change in the entire repository, and I don't want to be building node/javawhat if only rust/zcini has changed.
Therefore I have a few questions:
Is it possible to have a workflow only run when certain files have changed, rather than running everything every single time?
Is there a way to generalize my workflows so that every dir in rust/ uses the same generic workflow, or will I need one workflow per project in the repository?

Why is GitHub's Atom autocomplete suggesting symbols with one character truncated from the end?

i'm not sure why/when this started, but frequently I get an auto-suggestion for a value that exists in my code, but with the last letter missing. It's not one single case, it happens a lot.
I'm running version 1.6.0
Here's my package list:
Built-in Atom packages (89)
├── about#1.3.0
├── archive-view#0.61.0
├── atom-dark-syntax#0.27.0
├── atom-dark-ui#0.51.0
├── atom-light-syntax#0.28.0
├── atom-light-ui#0.43.0
├── autocomplete-atom-api#0.10.0
├── autocomplete-css#0.11.0
├── autocomplete-html#0.7.2
├── autocomplete-plus#2.25.0
├── autocomplete-snippets#1.10.0
├── autoflow#0.27.0
├── autosave#0.23.0
├── background-tips#0.26.0
├── base16-tomorrow-dark-theme#1.1.0
├── base16-tomorrow-light-theme#1.1.1
├── bookmarks#0.38.2
├── bracket-matcher#0.79.0
├── command-palette#0.38.0
├── deprecation-cop#0.54.0
├── dev-live-reload#0.47.0
├── encoding-selector#0.21.0
├── exception-reporting#0.37.0
├── find-and-replace#0.197.4
├── fuzzy-finder#0.94.0
├── git-diff#0.57.0
├── go-to-line#0.30.0
├── grammar-selector#0.48.0
├── image-view#0.56.0
├── incompatible-packages#0.25.0
├── keybinding-resolver#0.33.0
├── language-c#0.51.1
├── language-clojure#0.19.1
├── language-coffee-script#0.46.0
├── language-csharp#0.11.0
├── language-css#0.36.0
├── language-gfm#0.84.0
├── language-git#0.12.1
├── language-go#0.42.0
├── language-html#0.44.0
├── language-hyperlink#0.16.0
├── language-java#0.17.0
├── language-javascript#0.110.0
├── language-json#0.17.4
├── language-less#0.29.0
├── language-make#0.21.0
├── language-mustache#0.13.0
├── language-objective-c#0.15.1
├── language-perl#0.32.0
├── language-php#0.37.0
├── language-property-list#0.8.0
├── language-python#0.43.0
├── language-ruby#0.68.0
├── language-ruby-on-rails#0.25.0
├── language-sass#0.45.0
├── language-shellscript#0.21.0
├── language-source#0.9.0
├── language-sql#0.20.0
├── language-text#0.7.0
├── language-todo#0.27.0
├── language-toml#0.18.0
├── language-xml#0.34.2
├── language-yaml#0.25.1
├── line-ending-selector#0.3.0
├── link#0.31.0
├── markdown-preview#0.157.2
├── metrics#0.53.1
├── notifications#0.62.1
├── one-dark-syntax#1.2.0
├── one-dark-ui#1.1.9
├── one-light-syntax#1.2.0
├── one-light-ui#1.1.9
├── open-on-github#0.41.0
├── package-generator#0.41.0
├── settings-view#0.232.3
├── snippets#1.0.1
├── solarized-dark-syntax#1.0.0
├── solarized-light-syntax#1.0.0
├── spell-check#0.65.0
├── status-bar#0.83.0
├── styleguide#0.45.1
├── symbols-view#0.110.1
├── tabs#0.91.3
├── timecop#0.33.0
├── tree-view#0.203.2
├── update-package-dependencies#0.10.0
├── welcome#0.33.0
├── whitespace#0.32.1
└── wrap-guide#0.38.1
/Users/me/.atom/packages (26)
├── Stylus#1.0.0
├── activate-power-mode#0.4.1
├── atom-beautify#0.28.24
├── atom-jade#0.3.0
├── atom-material-ui#0.8.0
├── auto-indent#0.5.0
├── autoclose-html#0.22.0
├── emmet#2.4.1
├── file-icons#1.6.19
├── git-diff-details#0.20.0
├── highlight-selected#0.11.2
├── idiomatic-dark-syntax#0.1.3
├── language-cjsx#0.3.0
├── language-javascript-jsx#0.3.7
├── linter#1.11.3
├── linter-coffeelint#1.1.2
├── linter-eslint#5.2.6
├── merge-conflicts#1.3.2
├── pigments#0.26.0
├── predawn-ui#1.0.2
├── pretty-json#0.4.1
├── react#0.14.1
├── react-snippets#0.1.4
├── seti-ui#0.8.1
├── spacegray-dark-neue-ui#1.4.0
└── spacegray-dark-ui#0.12.0
As it turns out this is a defect in the language-cjsx package. If you open the Chrome Developer Tools with CtrlAltI and inspect the function name tokens as identified by the grammar there is an unnecessary span element surrounding the last character of every function name.
I have managed to solve this in my fork by simply removing the mapping between one of the capture groups and the grammar class. Whilst this works, a more elegant solution from Víctor Martínez is available that incorporates all of the recent changes from the CoffeeScript grammar package.
If you want to test this out you can follow the following process:
Uninstall the existing version of the language-cjsx package.
Clone one of the above two forks of language-cjsx to a known directory.
Run apm link <path-to-directory> to symlink the package to Atom's package directory.
Restart Atom with CtrlAltR.
Final Note: Víctor Martínez has subsequently noted that he is currently using orktes/atom-react to obtain syntax highlighting for CJSX based solutions.

Where does groovy look for properties files by default?

For this Netbeans project:
.
├── build.xml
├── manifest.mf
├── nbproject
│   ├── build-impl.xml
│   ├── genfiles.properties
│   ├── groovy-build.xml
│   ├── private
│   │   └── private.properties
│   ├── project.properties
│   └── project.xml
└── src
├── Config1.groovy
└── net
└── bounceme
└── mordor
└── groovy
└── file_ops
└── NewGroovyScript.groovy
8 directories, 10 files
what would the standard location, or path, for foo.properties so that it can be easily picked up? in src?
You should be able to stick it in the same folder as your NewGroovyScript.groovy class file, then just do:
Properties p = NewGroovyScript.class.getResource('foo.properties').withInputStream { s ->
Properties properties = new Properties()
properties.load(s)
properties
}

Including directories for doxygen documentation

I have a collection of .dox documentation files for my project
in a dox directory as illustrated below
In the input section I have included ../ for doxygen to pick up the source code. However when I put ./ it does not pick up my documentation files and have to include each file. Is there a way to include them automatically?
Here is the docs and lib directories. In lib I have the source code, whereas in docs I have the documentation.
../
├── docs
│ ├── dox
│ └── Doxyfile
└── lib
Here is the contents of the dox directory
./dox/
├── gnu_affero_gpl.dox
├── gnu_fdl.dox
├── gnu_gpl.dox
├── larsa
│   └── larsa_core.dox
├── larsa.dox
├── meidum
│   ├── lattices
│   ├── lattices.dox
│   ├── lattices.dox~
│   ├── polyhedra
│   └── polyhedra.dox
├── meidum.dox
├── modules.dox
└── vikingr.dox
I have now fixed the problem. The solution was to remember to add *.dox in FILE_PATTERNS variable in Doxyfile.

Standard CoffeeScript output layout

Is there any de facto standard for the filesystem output layout of compiled CoffeeScript output?
Or: where should the .js and .map files end up?
I currently have a file watcher1 compiling the output to ./grounds/[whatever] to keep the source folder clean, so I end up with something like:
index.html
/js
├──foo.js
├──bar.js
/coffee
├──a.coffee
├──b.coffee
├──/grounds
│ ├──a.js
│ ├──a.map
│ ├──b.js
│ ├──b.map
├──/some-module
│ ├──c.coffee
│ ├──/grounds
│ │ ├──c.js
│ │ ├──c.map
Just curious if I missed the boat on some existing standard for the output file layout, or if folks generally just let them all be siblings in the same folder and are happy with that.
1: Pycharm
I don't think they is any standard, but for development, I use the same structure for the JS than for the coffee:
eg:
coffee
├── AdvancedStatsModule.coffee
├── board
│   ├── Board.coffee
│   ├── Card.coffee
├── controllers
│   ├── directives.coffee
│   ├── factory.coffee
│   ├── filters.coffee
│   ├── ListController.coffee
public/js
├── AdvancedStatsModule.js
├── board
│   ├── Board.js
│   ├── Card.js
├── controllers
│   ├── directives.js
│   ├── factory.js
│   ├── filters.js
│   ├── ListController.js
Advantages for this:
JS and coffee are not mixed
The coffee directory is not public
For production, I usually concat and minify my files anyway.
Update:
I use gulp for that. My Gulpfile:
var watch= require('gulp-watch');
var coffee= require('gulp-coffee');
gulp.src(paths.coffee)
.pipe(watch(function(files) {
return files.pipe(coffee())
.pipe(gulp.dest(paths.js));
}));