Trying to compile Hugin: what is this MSGFMT error?

[David W. Jones]

I just cloned the Hugin repository from mercurial and followed the
instructions in INSTALL_cmake.

I get this from cmake. Ideas?

CMake Error at translations/CMakeLists.txt:7 (find_package):
By not providing "FindMSGFMT.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by
"MSGFMT", but
CMake did not find one.

Could not find a package configuration file provided by "MSGFMT" with any
of the following names:

MSGFMTConfig.cmake
msgfmt-config.cmake

Add the installation prefix of "MSGFMT" to CMAKE_PREFIX_PATH or set
"MSGFMT_DIR" to a directory containing one of the above files. If
"MSGFMT"
provides a separate development package or SDK, be sure it has been
installed.


-- Configuring incomplete, errors occurred!

--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.

[Gunter Königsmann]

Either you haven't gettext installed or your cake is too old to know about it.

[David W. Jones]

On 10/4/22 20:40, Gunter Königsmann wrote:
> Either you haven't gettext installed

I have gettext 0.21-4 installed.

> or your cake is too old to know about it.

Cake? You mean cmake? cmake is v3.18.4.

This is on Debian 11. It's been almost a year since the last time I
compiled Hugin. I successfully compiled Hugin 2021 to a /usr/local
installation 1 January 2022.

Ideas?

[Kornel Benko]

Am Tue, 4 Oct 2022 21:54:17 -1000
schrieb "David W. Jones" <gnome...@gmail.com>:

> On 10/4/22 20:40, Gunter Königsmann wrote:
> > Either you haven't gettext installed
>
> I have gettext 0.21-4 installed.
>
> > or your cake is too old to know about it.
>
> Cake? You mean cmake? cmake is v3.18.4.
>
> This is on Debian 11. It's been almost a year since the last time I
> compiled Hugin. I successfully compiled Hugin 2021 to a /usr/local
> installation 1 January 2022.
>
> Ideas?
>

It is part of hugin sources. Don't know, why cmake is not finding it.

Look foe 'CMakeModules/FindMSGFMT.cmake' in your cloned hugin.

Kornel

[David W. Jones]

I find that one in the cloned hugin tree. Cmake is still not finding
MSGFMT, although that is installed.

Here's what cmake tells me:

CMake Error at celeste/CMakeLists.txt:71 (set_target_properties):
set_target_properties called with incorrect number of arguments.

CMake Error at translations/CMakeLists.txt:7 (find_package):
By not providing "FindMSGFMT.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by
"MSGFMT", but
CMake did not find one.

Could not find a package configuration file provided by "MSGFMT" with any
of the following names:

MSGFMTConfig.cmake
msgfmt-config.cmake

Add the installation prefix of "MSGFMT" to CMAKE_PREFIX_PATH or set
"MSGFMT_DIR" to a directory containing one of the above files. If
"MSGFMT"
provides a separate development package or SDK, be sure it has been
installed.

Gettext and msgfmt are installed here.

Anyway, here's what finally worked:

1. Run "cmake .." in the build directory. That put the missing MSGFMT
.cmake files in a subfolder under the build directory.

2. Run "make".

3. Run "sudo make install".

That gave me a Hugin reporting itself as "Version: Pre-Release
2021.1.0.33b93e37f209". Is that correct?

[Kornel Benko]

Am Wed, 5 Oct 2022 17:25:43 -1000

Looks so, but why don't you use 'make package'? That way. you should get a file like
hugin-2021.1.0.8500-Linux.deb, which may be installed with
# sudo dpkg -i hugin-2021.1.0.8500-Linux.deb

To enable package creation, you may need to configure withthe parameter
CPACK_BINARY_DEB:BOOL=ON, e.g.
$ cmake -DCPACK_BINARY_DEB:BOOL=ON ...

Kornel

[johnfi...@gmail.com]

How is what finally worked different from what earlier didn't work?

For example, the instructions had /PATH/TO/HUGIN/SOURCES where your final working version had ..

I assume .. is the path to hugin sources (from the place where you had your build directory).

It is starting to sound like there was a problem in that aspect originally.

I personally would not make the build directory of a complicated open source project be a sub directory of the repository (except in projects with brain dead build tools giving you no choice).

As you discovered, that method does work.  But it still is not a great idea.

[johnfi...@gmail.com]

On Thursday, October 6, 2022 at 7:38:43 AM UTC-4 kornel wrote:

 why don't you use 'make package'? That way. you should get a file like
hugin-2021.1.0.8500-Linux.deb, which may be installed with
# sudo dpkg -i hugin-2021.1.0.8500-Linux.deb

I have no guess why the OP chose not to do that.  But I always choose not to do that because I want to build and test my own binaries separate and not interfering with downloading and testing the distribution's binaries.

Feel free to teach me something about the process that I am misunderstanding (I'm an expert C++ programmer, stumbling around in the dark on many of the build vs. distribution topics), but so far as I have discovered, building all the way to an installable package makes it harder to do an isolated test of your new binaries.

[Kornel Benko]

Am Thu, 6 Oct 2022 07:33:15 -0700 (PDT)
schrieb "johnfi...@gmail.com" <johnfi...@gmail.com>:

Why is it harder? There is only one step extra involved.
You have
$ make all
$ sudo make install
while with package you use
$ make package
which includes 'make all', and
$ dpkg -i <package>
which makes the install

There is no difference for testing IMO.

Kornel

[David W. Jones]

What I was trying to do earlier was specifying too much on the command
line. Combined with confusion about what "/PATH/TO/HUGIN/SOURCES" meant.
I interpreted it to mean it needed to point to the /src directory, when
it really means the parent directory of /src.

Sometimes I find compilation instructions too complex for their own
good. I know, they have to be general enough to cover a lot of
situations, but sometimes I think they're too general, trying to cover
too many possible situations. ;)

Or they're too specific. I use Debian, not Ubuntu/Fedora/Redhat, so
detailed instructions on how to do it under those other distros don't
necessarily help. ;)

Either way, it beats the days when I had to use alien to convert an RPM
to a DEB because developers only developed for Redhat.

On make install vs make package then install, when I compiled in January
2022, I used the make package option and installed the resulting
package. This time I decided not to make the package. No particular
reason, just what I did this time.

I can see one benefit to making a package and keeping it around. If I
needed to uninstall and reinstall, being able to re-install using the
package would be faster. So I went back just now and made a package to
keep around just in case.

Thanks for the help and advice!

On 10/6/22 04:26, johnfi...@gmail.com wrote:
> How is what finally worked different from what earlier didn't work?
>
> For example, the instructions had /PATH/TO/HUGIN/SOURCES where your
> final working version had ..

> I assume.. is the path to hugin sources (from the place where you had