I'm trying to figure out how to have automake change the file permissions on a newly generated executable automatically. Essentially, I want it to perform a 'chmod' every time it creates the executable, but I can't find anything that allows me to specify arbitrary shell commands after compilation. Any suggestions?
Thanks a lot,
Kyle
If you use the standard variables such as bin_PROGRAMS and bin_SCRIPTS, the installed files should be made executable automatically. For other uses you could use a hook target such as install-exec-hook or install-data-hook. This is described in the documentation and in the autobook.
Related
A user of xnec2c was trying to build on OSX and had autoconf issues because PKG_CHECK_MODULES could not be found since MacPorts puts it in a funny spot.
The user made autoconf work like so:
ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh
ACLOCAL_PATH=/opt/local/share/aclocal ./configure
I would like to make it build on OSX without special user path hacks for ACLOCAL_PATH. Can that be done?
I started writing a possible fix below and realized it could an xyproblem so posed the question just above. However, if this starts any gears turning, then I would be open to a bit of special-casing for OSX:
For example, would it be possible (if not advisable) to detect:
Is PKG_CHECK_MODULES missing?
If so:
is it OSX?
Is [ -d /opt/local/share/aclocal ] true?
Does the macro exist there?
While aclocal has a few ways of appending to its search path (see https://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html), you cannot modify that macro search path using code in configure.ac:
When the shell code in configure is run, it is too late, as the available macros have already been expanded. When autoconf (is it autoconf or something else? anyway, m4 called from autoreconf) generates configure from configure.ac by having m4 expand the macros it is also too late: aclocal has already collected the m4 macros it could find.
So what you would need is a step before the autoreconf run - which is beyond what I would consider a buildsystem needs to do.
What you can do: Put static strings into the top level Makefile.am file like e.g.
ACLOCAL_AMFLAGS = -I auto-m4 -I project-m4 -I /opt/local/share/aclocal
(this example uses auto-m4/ with AC_CONFIG_MACRO_DIR([auto-m4]) for the *.m4 files automatically put there by autoreconf/autopoint/libtoolize and project-m4/ for the project specific *.m4 files).
Of course, you should already have
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
before invoking PKG_CHECK_MODULES for the first time so that the problem of the missing *.m4 file will be detected at the earliest possible time, i.e. when autoconf is about to generate a configure file with PKG_CHECK_MODULES unexpanded.
You could use some m4 code to print a lengthy error message if PKG_CHECK_MODULES is not defined. Something along the lines of (untested)
m4_ifndef([PKG_CHECK_MODULES], [dnl
m4_fatal([Could not find the PKG_CHECK_MODULES macro. Check that the pkg.m4 file is available and aclocal finds it (e.g. set ACLOCAL_PATH=/opt/local/share/aclocal).
])dnl
PKG_CHECK_MODULES([FOO], [foo])
Personally, I would go with m4_pattern_forbid and make sure OSX builds with homebrew work OOTB, and then document idiosyncrasies for building on rare and buggy systems like OSX with macports or SunOS without GNU tools in the INSTALL file.
Isn't it a bug in macports/OSX that aclocal there cannot find its *.m4 files? Shouldn't there be a dirlist file pointing to /opt/local/share/aclocal? Or perhaps they macports users should have an aclocal in their PATH which actually finds the macports macro files?
In any case, I would not consider it my build systems's job to fix a buggy system. You need to draw the line somewhere.
I would like to release my program that wrote in ruby language, I need to pack ruby to appimage file and send it to my client ubuntu PC first.
so I create the folder "ruby-img", then copy my compiled ruby which in "/app/ruby" folder to "ruby-img/app/ruby" and then made a link as "ln -r -s app/ruby/bin/ruby usr/bin/." in "ruby-img" folder.
then I create the desktop file and put png file to "ruby-img", using appimagetool to create ruby-x86_64.AppImage. sadly it can not run, AFAIK that ruby.AppImage still using /app/ruby/lib folder to find some library of ruby but not in "ruby-img/app/ruby/lib" related folder.
so I tried re-compile ruby as --prefix=/tmp/ruby or --prefix=/usr/local/ruby, then copy them to "ruby-img/usr/local/ruby" or "ruby-img/tmp/ruby" then maka some link as above, and repack to AppImage but ruby.AppImage still not working...
any idea can help me ?
AppImages contain of a filesystem with all the content you provide plus a small executable stub that will mount the AppImage filesystem, then run the AppRun executable to be found inside.
With that knowledge it is utmost important that you provide an executable in the root directory along with the .desktop and icon files. I suggest you do not create AppRun yourself. Use the precompiled one from https://github.com/AppImage/AppImageKit/releases/tag/continuous (do not forget to rename it to exactly 'AppRun').
Now when this AppRun gets invoked, it will perform a few checks, cd into the /usr directory and try to start the executable specified in the .desktop file. Check it's source code and you can see that it also sets a few environment variables.
Therefore it is best you provide your entrypoint as /usr/bin/ruby.sh and register that in the desktop file. Remember if /usr/bin/ruby.sh gets called, the current work directory is /usr. So ruby.sh can set further environment variables such as LD_LIBRARY_PATH so that the libraries you configured for /usr/lib will actually be loaded.
With that I hope you have at least as much success as I had.
This question has been asked many time but I am not able to resolve the problem from them so I am asking
I had installed Cygwin a few days ago.I tried using ./configure command but it says
-bash: ./configure: No such file or directory
I tried using
where configure
but I got the output
INFO: Could not find files for the given pattern(s).
then I tried grep configureand I got this output
/etc/bash_completion.d/configure
/usr/i686-pc-cygwin/sys-root/usr/share/libtool/libltdl/configure
/usr/share/ELFIO/configure
/usr/share/libtool/libltdl/configure
I tried to export the path and then run the ./configure but it also didn't worked.
I find no executable file named as configure in my cygwin bin directory.
Does it mean that I have to add configure file manually?How can I correct it?
NOTE :- I had also tried sh configure but it also didn't worked
If a software project is set up to be built using autoconf, that tool generates a script canonically called configure. It queries the system for various parameters that are subsequently used in the build, and is specific to the software package to be built. Different software projects have different configure scripts. They are all called configure, but their contents are not the same.
So, to actually build such a software project once that script was set up (usually done by the maintainers when packaging the source tarball for distribution), you call:
tar xzf <tarball>.gz # or xjf <tarball>.bz2 or whatever
cd <sourcedir> # the one you just untarred
./configure
make
make install
Note the prefix ./, which means "located in this directory" (i.e. the top directory of that project's source tree).
Actually, the better procedure is the so-called "out-of-tree build", when you set up a different directory for the binaries to be built in, so the source tree remains unmodified:
tar xzf <tarball>.gz # or xjf <tarball>.bz2 or whatever
mkdir builddir
cd builddir
../<sourcedir>/configure
make
make install
So, there is supposed to be no configure executable in your PATH, you are supposed to call the script of that name from the source tree you are trying to build from.
If I correctly understood...
Configure is not an application that should be installed on your system, but script that should be delivered with source code to prepare for make command. File named configure should be in the main directory of source code.
I understand that this is an old question. However many might find this solution helpful.
Normally we use the make command to compile a downloaded source in cygwin. In many cases it contains a autogen.sh file. Running that file with
bash autogen.sh
will in many case solve the problem. At least it solved my issue and i could then use the make command
I am making a configure.ac file for a tool i made and i need to check whether pdflatex is installed in the users system. How do i do it ? For checking for other libraries i simply included the test programs using AC_COMPILE_IFELSE, but i dont know if pdflatex can be invoked from the program.
Also is it regular practise to install all the required packages automatically using some script or i can just specify in the readme file which packages are required and then its upto user to install those packages.
You can use AC_CHECK_PROG([have_pdflatex], [pdflatex], [yes], [no]) to simply check if it exists and set have_pdflatex to yes if so. It's more likely that you'll want to use AC_PATH_PROG([PDFLATEX], [pdflatex]) to find the actual path of the program if it exists and store it in PDFLATEX.
I think it's best to let the user install the prerequisites themself. You don't know how they install their software (apt? yum? pacman? emerge? source?) and it wouldn't be worth the effort to try to cover all cases. It's sufficient to just mention them in the README and to test for them with Autoconf macros.
I'm creating a Linux tgz self-extracting installer using CPack and I'd like the installer to run a script or sequence of commands after all files have been installed. CPack documentation contains the following guidance:
CPACK_INSTALL_COMMANDS Extra commands to install components.
I set this variable in my CMakeLists.txt file and I see it set in the resulting CPackConfig.cmake file, but the commands I embed in this variable do not appear anywhere in the final .sh install script. What am I missing?
You're not missing anything, that's simply not how the CPACK_INSTALL_COMMANDS variable works.
On a typical project, CPack does a "make install" into a temporary location, in order to build the final installer based on the "make install" tree. The CPACK_INSTALL_COMMANDS variable is meant to be set for projects that would rather run some other command sequence, instead of the typical "make install" in order to produce the install tree.
So, CPack should be running your commands as it generates the package. It will not run your commands on the end user's machine at the end of him/her running the generated installation script...
There are per-generator ways of running installed executables and/or scripts at the end of the end user installation, but it will require some customization on your part. In this case, I'd recommend attempting to override the CPack.STGZ_Header.sh.in input file that is used when CPack generates the STGZ self-extracting script. Customize that file and add your calls to the bottom of it, above the line:
exit 0
To override the file, provide your own copy of it in your source tree, perhaps in a ${CMAKE_CURRENT_SOURCE_DIR}/CMake directory, and then in your CMakeLists.txt file, add:
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/CMake ${CMAKE_MODULE_PATH})
(Actually, as I'm writing this, I'm wondering if that's sufficient, or if the module path also needs to be set at the time that CPack runs... Try this, and let us know if your customization gets used by CPack or not. If not, I'll investigate a bit further and add some more advice here.)