I have been able to successfully compile Tcl/Tk Frameworks on macOS (following instructions here). I use these Frameworks inside an .app for distributions. I would like to customize my Frameworks adding extra extensions, for example Drag&Drop TkDND (by the way, I really think this basic GUI feature should be integral part of Tk...).
Instructions here seem to refer to adding the extension to a normal installation, not a Framework. I haven't found any explicit instructions. Sorry if the question is naive, but I am very unexperienced of Tcl/Tk. PS: my .app accesses Tk through Perl. I would very much appreciate any help/instructions/link.
I don't use tkdnd, so I do not have a answer specific to that installation.
Adding to my script I have blocks in my build script such as this one which builds the 'tdom' extension.
cd $SRCDIR
cd tdom*
if [[ $? -eq 0 ]]; then
make distclean
./configure \
--exec-prefix=$INSTLOC \
--prefix=$INSTLOC \
--with-tcl=$INSTLOC/Library/Frameworks/Tcl.framework/tclConfig.sh
make CFLAGS="-O2 -mmacosx-version-min=${macosxminver}"
make install
fi
However, linking to the Tk libraries may complicate things. And every package is different and uses different variables. So I will need to download tkdnd and build it and see if there are any issues, so expect an upcoming edit to this answer.
(Edit: I fixed the script in the original question, so the following
paragraph no longer applies)
My changes to the init.tcl script are not quite perfect, as you can see, the wrong package is loaded when I run via 'wish' (wish is in a different location than tclsh, which causes some issues). I should have the local installation's path located earlier in the auto_path. If you are using my script, you need to be aware of this.
bll-mac:$ ../darwin/64/tcl/bin/tclsh
% package require tdom
0.9.1
bll-mac$ ../darwin/64/tcl/bin/wish
% package require tdom
0.8.3
% package require tdom 0.9.1
0.9.1
There really isn't any difference between a framework (and b) and a normal installation, the framework just provides a structure for resource location.
Edit:
It appears that the following works to compile and install the tkdnd package.
The redefinition of PKG_CFLAGS is necessary because the tkdnd makefile
has an argument defined that is not supported by the compiler (on Mojave).
So PKG_CFLAGS is a copy of what's in the makefile without -fobjc-gc.
I only tried doing a package require tkdnd. I don't know how to use
the package, so I did not try anything else.
cd $SRCDIR
cd tkdnd*
if [[ $? -eq 0 ]]; then
make distclean
./configure \
--prefix=$INSTLOC \
--exec-prefix=$INSTLOC \
--with-tcl=$INSTLOC/Library/Frameworks/Tcl.framework \
--with-tk=$INSTLOC/Library/Frameworks/Tk.framework
make CLAGS_OPTIMIZE="-O2 -mmacosx-version-min=${macosxminver}" \
PKG_CFLAGS="-DMAC_TK_COCOA -std=gnu99 -x objective-c"
make install
fi
This seems to install the extension in the standard path (/usr/local/lib) but not in the Tk.framework. Probably the "make instal" should require some extra values.
Related
I'm not really experienced with graphics programming, but I got curious. I installed both libgtk-3-dev and gtk-3-examples on my Debian 10.7 machine. From there I listed the example package files using dpkg-query -L gtk-3-examples to find some example programs.
In the examples directory I found the following README file:
== Building the examples ==
The examples in this directory are built alongside the rest of GTK+.
The examples under the `application[1-10]` directories are also included in
the GTK+ API reference documentation, and can be built independently, using
the system libraries, by doing:
$ cd application1
$ make -f Makefile.example
Looks straight forward. However, following the directions exactly yields the following result:
make: Makefile.example: No such file or directory
make: *** No rule to make target 'Makefile.example'. Stop.
There are no "Makefile.example" files in the application folders. Running find -name "Makefile*" in the examples directory yields:
./application7/Makefile.in.gz
./application7/Makefile.am
./Makefile.in.gz
./application5/Makefile.in.gz
./application5/Makefile.am
./bp/Makefile.in.gz
./bp/Makefile.am
./application9/Makefile.in.gz
./application9/Makefile.am
./application6/Makefile.in.gz
./application6/Makefile.am
./application2/Makefile.in.gz
./application2/Makefile.am
./application10/Makefile.in.gz
./application10/Makefile.am
./application3/Makefile.in.gz
./application3/Makefile.am
./application1/Makefile.in.gz
./application1/Makefile.am
./application8/Makefile.in.gz
./application8/Makefile.am
./application4/Makefile.in.gz
./application4/Makefile.am
./Makefile.am
I've not had any luck building an example program using the above files. I'm guessing it is because of my unfamiliarity with auto tools? Is there an easy way to build an example GTK program using the above files or do I need know a lot more about make/autotools/configure to get a working example running?
Update:
The cant-run-makefile-am-what-should-i-do post is informative but does not provide a course of action when no configure, bootstrap, or autogen programs can be found within the package. The following command yields no results when executed in my examples directory: find -type f | grep -i -E "*conf*|*auto*|*boot*". I need one of those files to be provided in order to have a successful build (as far as I understand it anyway).
Sorry for the fuss! I'm used to installing regular packages and missed that I needed to download the full source code to get the examples working. So, originally I mentioned that I installed both libgtk-3-dev and gtk-3-examples. I did so using apt-get install libgtk-3-dev && apt-get install gtk-3-examples.
However, to build GTK along with its examples locally it looks like what you want to do is get the source package archive with apt-get source gtk-3-examples (or similar.. I think it actually picked a different meta-package for me when I ran that command).
Then, in my new gtk+3.0-3.24.5 directory there's a nice configure binary that I can run (with subsequent make and make install commands) which produce many files including example program binaries.
So with ./gtk+3.0-3.24.5/examples/application1/exampleapp I get a running example. Voila!
I am trying to install the openCV library for Python however I am new to CMake and have run into some trouble after having cloned the repository in ~/opencv.
I've made a build directory in it with the mkdir command however once inside it when trying to set CMake options in it.
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local
I get prompted with the following error:
CMake Error: The source directory "/Users/eDen/opencv/build/CMAKE_INSTALL_PREFIX=/usr/local" does not exist.
It seems you aren't making the right directory, some Mac OS X installations doesn't include /usr/local/. You can make the directory using, if it's not already created, with:
sudo mkdir /usr/local/
But you say you want to use OpenCV with Python. I recommend you to obtain an already compiled copy unless you need some advanced features not available in the compiled version, like Qt integration or CUDA programming. But these features are included in the arguments of the cmake command.
Instructions on how to obtain OpenCV from Homebrew repository, this page explains the process. Basically, you install Homebrew, then Python, configure it and install some dependencies.
As Tsyvarev mentioned in the comments, you need to specify the path to source directory (i.e. where the main CMakeLists.txt file exists) at the end of your command. So, supposing you are now in the build directory, the final cmake command would be as follows:
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local ..
I have the last argument as .. but still get the error.
In my case, there is a bad whitespace in the above arguments. So the last .. is ignored.
First, a little bit of background as to why I'm asking this question: Our product's daily build script (as run under Debian Linux by Jenkins), does roughly this:
Creates and enters a build environment using debootstrap and chroot
Checks out our codebase (including some 3rd party libraries) from SVN
Runs configure and make as necessary to build all of the code
Packages up the results into an install file that can be uploaded to our headless server boxes using our install tool.
This mostly works fine, but every so often (maybe one daily build out of 10), the part of the script that builds one of our third-party libraries will error out with an error like this one:
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
/root/software/3rdparty/libogg/missing autoconf
/root/software/3rdparty/libogg/missing: line 81: autoconf: command not found
WARNING: 'autoconf' is missing on your system.
You should only need it if you modified 'configure.ac',
or m4 files included by it.
The 'autoconf' program is part of the GNU Autoconf package:
<http://www.gnu.org/software/autoconf/>
It also requires GNU m4 and Perl in order to run:
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
make: *** [configure] Error 127
As far as I can tell, this happens occasionally because the timestamps of the files in the third-party library are different (e.g. off by a second or two from each other just due to the timing of when they were checked out from the SVN server during that particular build). That causes the configure script to think that it needs to auto-regenerate a file, so then it tries to call 'automake' to do so, and errors out because automake is not installed.
Of course the obvious thing to do here would be to install automake in the build environment, but the build environment is not one that I can easily modify (due to institutional reasons), so I'd like to avoid having to do that if possible. What I'd like to do instead is figure out how to get the configure scripts (which I can modify) to ignore the timestamps and just always do the basic build that they do when the timestamps are equal.
I tried to finesse the problem by manually running 'touch' on some files to force their timestamps to be the same, and that seemed to make the problem occur less often, but it still happens:
./configure --prefix="$PREFIX" --disable-shared --enable-static && \
touch config* aclocal* Makefile* && \
make clean && make install ) || Failure "libogg"
Can anyone familiar with how automake works supply some advice on how I might make the "configure" calls in our daily build work more reliably, without modifying the build environment?
You could try forcing SVN to use commit times on checkout on your Jenkins server. These commit times can also be set in SVN if they don't work out for some reason. You could use touch -d or touch -r instead of just touch to avoid race conditions there.
I am trying make/install inkscape on WinXp. Although I am rather inexperienced on this subject, I have a reasonably well developed MingW infrastructure, and have successfully built/installed a variety of packages, such as Cairo, Pango, GTK+, Glade, etc.
At the moment I am trying to make/install inkscape. Following a huge amount of work, it all configures and compiles, with MSys:
cd ${LOCALBUILDDIR} && \
cd inkscape-0.91 && \
./configure --prefix=${LOCALDESTDIR} CFLAGS='-std=gnu++11' CXXFLAGS='-std=gnu++11' && \
make CFLAGS='-std=gnu++11' CXXFLAGS='-std=gnu++11' && \
make install
and after successful config/compile I use
cd ${LOCALBUILDDIR} && \
cd inkscape-0.91 && \
make CFLAGS='-std=gnu++11' CXXFLAGS='-std=gnu++11' && \
make install
to prevent recreating/overwriting the config etc files for the edits discussed below.
This fails on the link with:
make[3]: Entering directory `/build32/inkscape-0.91/src'
CXXLD inkscape.exe
libtool: link: cannot find the library `/usr/lib/libintl.la' or unhandled argument `/usr/lib/libintl.la'
At no time ever have I had any Dir's called "/usr". I appreciate that is the default on Unix etc, but my installation has its libs in D:/Apps/MingW/local32/lib", and which certainly includes libintl.la (and all the required gettext and libintl bits, as it would need for the success with all the other packages). Indeed, the inkscape configure and compile steps report finding libintl etc. correctly. Also, it obtains the path correctly for the compiler, etc. as it would need to for the success with the compiler.
I am guessing that somewhere in the inkscape configure/in/ac/m4 etc bits, it has hard-wired, or something, the link step for libintl for Unix default. I have tried many permutations to manually alter "/usr/lib" lines in the config and libtool files, but obtain the same link crash.
I would be grateful for any hints as to where to look for/correct this in inkscape (or even generally).
OK, sussed it. It wasn't libintl per se, even though that is the "error/crash message".
The problem was in libpopt.la, which had hardwired "/usr/lib" dependency, rather than correctly creating the .la for the Windows/MingW environment.
popt was required for inkscape.
I kept running AgenRansack on the inkscape build dir's looking for "/usr" etc, when I should have run AgentRansack on my /local32/lib dir.
It now compiles and links without complaint ... but doesn't launch ... oh well, on to that later :-(
How can I put my Go binary into a Debian package? Since Go is statically linked, I just have a single executable--I don't need a lot of complicated project metadata information. Is there a simple way to package the executable and resource files without going through the trauma of debuild?
I've looked all over for existing questions; however, all of my research turns up questions/answers about a .deb file containing the golang development environment (i.e., what you would get if you do sudo apt-get install golang-go).
Well. I think the only "trauma" of debuild is that it runs lintian after building the package, and it's lintian who tries to spot problems with your package.
So there are two ways to combat the situation:
Do not use debuild: this tool merely calls dpkg-buildpackage which really does the necessary powerlifting. The usual call to build a binary package is dpkg-buildpackage -us -uc -b. You still might call debuild for other purposes, like debuild clean for instance.
Add the so-called "lintian override" which can be used to make lintian turn a blind eye to selected problems with your package which, you insist, are not problems.
Both approaches imply that you do not attempt to build your application by the packaging tools but rather treat it as a blob which is just wrapped to a package. This would require slightly abstraining from the normal way debian/rules work (to not attempt to build anything).
Another solution which might be possible (and is really way more Debian-ish) is to try to use gcc-go (plus gold for linking): since it's a GCC front-end, this tool produces a dynamically-linked application (which links against libgo or something like this). I, personally, have no experience with it yet, and would only consider using it if you intend to try to push your package into the Debian proper.
Regarding the general question of packaging Go programs for Debian, you might find the following resources useful:
This thread started on go-nuts by one of Go for Debian packagers.
In particular, the first post in that thread links to this discussion on debian-devel.
The second thread on debian-devel regarding that same problem (it's a logical continuation of the former thread).
Update on 2015-10-15.
(Since this post appears to still be searched and found and studied by people I've decided to update it to better reflec the current state of affairs.)
Since then the situation with packaging Go apps and packages got improved dramatically, and it's possible to build a Debian package using "classic" Go (the so-called gc suite originating from Google) rather than gcc-go.
And there exist a good infrastructure for packages as well.
The key tool to use when debianizing a Go program now is dh-golang described here.
I've just been looking into this myself, and I'm basically there.
Synopsis
By 'borrowing' from the 'package' branch from one of Canonical's existing Go projects, you can build your package with dpkg-buildpackage.
install dependencies and grab a 'package' branch from another repo.
# I think this list of packages is enough. May need dpkg-dev aswell.
sudo apt-get install bzr debhelper build-essential golang-go
bzr branch lp:~niemeyer/cobzr/package mypackage-build
cd mypackage-build
Edit the metadata.
edit debian/control file (name, version, source). You may need to change the golang-stable dependency to golang-go.
The debian/control file is the manifest. Note the 'build dependencies' (Build-Depends: debhelper (>= 7.0.50~), golang-stable) and the 3 architectures. Using Ubuntu (without the gophers ppa), I had to change golang-stable to golang-go.
edit debian/rules file (put your package name in place of cobzr).
The debian/rules file is basically a 'make' file, and it shows how the package is built. In this case they are relying heavily on debhelper. Here they set up GOPATH, and invoke 'go install'.
Here's the magic 'go install' line:
cd $(GOPATH)/src && find * -name '*.go' -exec dirname {} \; | xargs -n1 go install
Also update the copyright file, readme, licence, etc.
Put your source inside the src folder. e.g.
git clone https://github.com/yourgithubusername/yourpackagename src/github.com/yourgithubusername/yourpackagename
or e.g.2
cp .../yourpackage/ src/
build the package
# -us -uc skips package signing.
dpkg-buildpackage -us -uc
This should produce a binary .deb file for your architecture, plus the 'source deb' (.tgz) and the source deb description file (.dsc).
More details
So, I realised that Canonical (the Ubuntu people) are using Go, and building .deb packages for some of their Go projects. Ubuntu is based on Debian, so for the most part the same approach should apply to both distributions (dependency names may vary slightly).
You'll find a few Go-based packages in Ubuntu's Launchpad repositories. So far I've found cobzr (git-style branching for bzr) and juju-core (a devops project, being ported from Python).
Both of these projects have both a 'trunk' and a 'package' branch, and you can see the debian/ folder inside the package branch. The 2 most important files here are debian/control and debian/rules - I have linked to 'browse source'.
Finally
Something I haven't covered is cross-compiling your package (to the other 2 architectures of the 3, 386/arm/amd64). Cross-compiling isn't too tricky in go (you need to build the toolchain for each target platform, and then set some ENV vars during 'go build'), and I've been working on a cross-compiler utility myself. Eventually I'll hopefully add .deb support into my utility, but first I need to crystallize this task.
Good luck. If you make any progress then please update my answer or add a comment. Thanks
Building deb or rpm packages from Go Applications is also very easy with fpm.
Grab it from rubygems:
gem install fpm
After building you binary, e.g. foobar, you can package it like this:
fpm -s dir -t deb -n foobar -v 0.0.1 foobar=/usr/bin/
fpm supports all sorts of advanced packaging options.
There is an official Debian policy document describing the packaging procedure for Go: https://go-team.pages.debian.net/packaging.html
For libraries: Use dh-make-golang to create a package skeleton. Name your package with a name derived from import path, with a -dev suffix, e.g. golang-github-lib-pq-dev. Specify the dependencies ont Depends: line. (These are source dependencies for building, not binary dependencies for running, since Go statically links all source.)
Installing the library package will install its source code to /usr/share/golang/src (possibly, the compiled libraries could go into .../pkg). Building depending Go packages will use the artifacts from those system-wide locations.
For executables: Use dh-golang to create the package. Specify dependencies in Build-Depends: line (see above regarding packaging the dependencies).
I recently discovered https://packager.io/ - I'm quite happy with what they're doing. Maybe open up one of the packages to see what they're doing?