Re: Docbook pdf generation - copying png images to build directory?
Ralf Wildenhues wrote: > * Daniel Leidert wrote on Fri, Nov 13, 2009 at 10:19:43PM CET: > > Clifford Yapp wrote: > > > I have a situation where I need to copy png images from a source > > > directory to the build directory prior to running other build rules, > > > and I am having some trouble formulating a rule to do the job. > > > Background: > > > > Does fop do the whole job? It's possible to use xsltproc to prepare > > the .fo file, which should then be easily processible by fop I guess. > > xsltproc knows a --path switch. I usually use: > > > > VPATH =+ $(srcdir) > > BTW, Automake sets VPATH to contain $(srcdir) if source and build tree > are separate, so this line should not be needed (=+ is also a typo), > if you ... > > > rule: > > xsltproc --path "$(VPATH)" ... > > ... just write --path "$(srcdir)" here instead. That way, you don't > pass "" if source and build trees coincide. It might be that I used to add $(builddir). I found these examples in my projects: VPATH += $(top_builddir)/src $(top_builddir)/xsl $(top_srcdir)/xsl XSLTPROC_FLAGS += --path "$(VPATH)" VPATH += @builddir@ XSLTPROC_FLAGS += --path "$(VPATH)" I will check my local copies as soon as I'm back. All I can say is, that the above works well (also if builddir != srcdir). Regards, Daniel -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
Re: Docbook pdf generation - copying png images to build directory?
Clifford Yapp wrote: > I have a situation where I need to copy png images from a source > directory to the build directory prior to running other build rules, > and I am having some trouble formulating a rule to do the job. > Background: Does fop do the whole job? It's possible to use xsltproc to prepare the .fo file, which should then be easily processible by fop I guess. xsltproc knows a --path switch. I usually use: VPATH =+ $(srcdir) rule: xsltproc --path "$(VPATH)" ... to catch all files in $(builddir) and $(srcdir). A different way would be to define the path to images via parameter and then set this parameter on xsltproc/fop call. For the first mentioned: xsltproc --stringparam image.path "$(srcdir)" This is how docbook-xsl works (to include the pictures for warnings, notes, ...). There is IMHO no need to copy the files around. Regards, Daniel -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Re: Define a complete rule via autoconf (quoting issue, AC_SUBST)
Am Dienstag, den 28.10.2008, 07:50 +0100 schrieb Ralf Wildenhues: > Hi Daniel, > > * Daniel Leidert wrote on Mon, Oct 27, 2008 at 11:04:34PM CET: > > > > I want to place a rule in several Makefiles. So I thought about putting > > > > @DESKTOP_DATA_RULE@ > > > > into every Makefile.am and define the rule via configure.ac. However, I > > can't get it to work. > > Should be possible with recent Autoconf. If you also use Automake, > however, you need to get it to not add > DESKTOP_DATA_RULE = @DESKTOP_DATA_RULE@ > > into the Makefile.in. Currently, that is only possible through an > undocumented Automake macro, _AM_SUBST_NOTMAKE([DESKTOP_DATA_RULE]). > The intention is to fix that for the next Automake release. > > If you still have problems after this, please show what you tried, > and what's output, and the error. I get errors running ./configure. I guess, this is, because of a problem with the quotation. Doing a simple: AC_SUBST([DESKTOP_DATA_RULE], [ target: requirements @list=... ]) doesn't work. The rerrors are related to the variables contained in the rule. But I did not find an example, how I need to escape special characters in the rule (or at least: which characters I need to escape). > Besides the workarounds already mentioned, other possibilities include > Automake conditionals. I now conditionally include a Makefile snippet, which contains the rules. > > $(desktop_DATA): $(desktop_in_files:.desktop.in=.desktop) > > @list='$<'; for p in $$list; do \ > > Please note that using $< outside of inference rules requires GNU make. The build system already uses some GNU make extensions (especially the gnome-doc-utils Makefile snippet requires GNU make), but I try to minimize its usage. So many thanks for your hints. But my Makefiles also require it, because the following works, but the install rules fail: schemas_DATA = `echo "$(schemas_in_files)" | sed 's/.schemas.in$$//;$(transform);s/$$/.schemas/'` Running the install target fails, because the installation rules do not expand this expression. Instead they try to install "`echo". So I need: schemas_DATA = $(shell echo "$(schemas_in_files)" | sed 's/.schemas.in$$//;$(transform);s/$$/.schemas/') and this works. Is there maybe a solution, which doesn't require GNU make here? Regards, Daniel
Re: pkg-config, anyone?
Am Freitag, den 10.10.2008, 22:21 +0200 schrieb Matěj Týč:
> Thank you for your reply, Dan
>
> > And where is the problem? E.g.
> >
> > Name: @PACKAGE@
> >
> This does not work. I need a name of the library that libtool produces
> in the end...
For what? The version numbers are not relevant here. Which field are you
trying to create? It is also possible to define variables in this file
and use them. Consider e.g. the GTK+ file:
[..]
target=x11
[..]
Libs: -L${libdir} -lgtk-${target}-2.0
Is this, what you want? It would probably help, if you give a short
example, what you expect.
[..]
> > BTW: Your question is not related to pkg-config. Maybe you want to consult
> > the
> > autotools lists.
> I actually did. This is the automake mailing list :-)
The price of having both lists :) I hope you don't mind.
Regards, Daniel
Re: pkg-config, anyone?
Matěj Týč wrote: > Hello friends, > I would like to inquire whether there is someone here that generates .pc > files in his autotools-powered project (presumably a project containing > libraries). > I am particulary searching for a manner how to specify the library name > in a smart way since libtool can be very creative when decorating the > library name (if you use the -version-number etc. options). > Imagine that you would like a library to have different name on each > platform and you would also like to generate and install a .pc file for > every one of those platforms. Obviously it would be very helpful if it > was possible using the same .pc.in template. And where is the problem? E.g. Name: @PACKAGE@ and then process the .pc.in by configure (AC_CONFIG_FILES). If you don't want to use $PACKAGE, well then use some self-defined variable. I guess your Makefiles also gets the library name from somewhere (e.g. configure). However, IMO it is a stupid idea to use different names for the same library on different platforms. It makes it hard to search for this library by a simple portable configure script. BTW: Your question is not related to pkg-config. Maybe you want to consult the autotools lists. Regards, Daniel -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
Re: Make syntax $(srcdir) in Makefile.am problem
Am Dienstag, den 12.02.2008, 10:39 -0500 schrieb db: > I am trying to run automake command in Fedora 7 (automake 1.10). Automake > fails due to GNU make extension: > > priv/Makefile.am:52: shell cat $(srcdir: non-POSIX variable name > priv/Makefile.am:52: (probably a GNU make extension) > > Makefile.am content, where the problem is: > $(shell cat $(srcdir)/test_con.txt) > > This means you can't have gnu make $(srcdir) syntax? No. It means that $(shell ...) is a GNU make extension. The warning (it's normally not an error except -Werror is used) is not related to $(srcdir). Regards, Daniel
Re: distcheck does not set exec_prefix - bug? distcheck fails for packages using e.g. pkglibdir
Am Mittwoch, den 17.10.2007, 02:41 +0200 schrieb Daniel Leidert:
> Hi,
>
> Today I observed an issue when I tried to run `make distcheck' as usual
> for one of the project I'm contributing to. The issue was, that
> distcheck failed at the step of installing a library. It told me, that
> it was not able to remove the library from
>
> /usr/local/lib/$package
>
> Of course I tried to find out, why distcheck tried to access /usr/local
> and found, that it doesn't set exec_prefix to $dc_install_base (I set
> exec_prefix to ${ac_default_prefix} if its value is "NONE", which is the
> default). It just sets prefix. But e.g. (pkg)libdir is based on
> exec_prefix (at least following the Makefiles produced on my system).
>
> So, shouldn't you set exec_prefix in distdir.am too? Or is there a bug
> missing to set exec_prefix to ${prefix}? Or am I misunderstanding
> something?
Hm. After removing the small snippet from configure.ac setting
exec_prefix to "/usr/local" if its value is "NONE" (IIRC I added it,
because it was necessary to fix its value), everything works and
exec_prefix is set to ${prefix}. I still wonder, if exec_prefix should
be set in the configure-call of the distcheck target to
workaround/prevent issues like mine.
Regards, Daniel
distcheck does not set exec_prefix - bug? distcheck fails for packages using e.g. pkglibdir
Hi,
Today I observed an issue when I tried to run `make distcheck' as usual
for one of the project I'm contributing to. The issue was, that
distcheck failed at the step of installing a library. It told me, that
it was not able to remove the library from
/usr/local/lib/$package
Of course I tried to find out, why distcheck tried to access /usr/local
and found, that it doesn't set exec_prefix to $dc_install_base (I set
exec_prefix to ${ac_default_prefix} if its value is "NONE", which is the
default). It just sets prefix. But e.g. (pkg)libdir is based on
exec_prefix (at least following the Makefiles produced on my system).
So, shouldn't you set exec_prefix in distdir.am too? Or is there a bug
missing to set exec_prefix to ${prefix}? Or am I misunderstanding
something?
System running is a recent Debian Sid with automake 1.10
Regards, Daniel
Re: ifdef ... endif issue
Am Sonntag, den 26.08.2007, 01:28 +0200 schrieb Benoit SIGOURE: > On Aug 26, 2007, at 12:04 AM, Daniel Leidert wrote: [..] > > I wanted to use this code in one of my Makefiles: > > > > ifdef WIN32_EXTRA_LDFLAGS > > WIN32_EXTRA_LDFLAGS += -export-symbols $(srcdir)/entities.def > > endif > > > > But that doesn't work. automake complains: > > > > src/plugin_entities/Makefile.am:22: WIN32_EXTRA_LDFLAGS must be set > > with > > `=' before using `+=' > > src/plugin_entities/Makefile.am:23: endif without if > > > > 1. Shouldn't automake stop complaining about setting > > WIN32_EXTRA_LDFLAGS > > first, when I test for its existence? > > > > 2. Why is automake complaining about the endif "without" if? The > > ifdef...endif condition is part of make and I know several Makefiles, > > that use it. Is it a bug in automake? > > I don't think you can do what you're trying to achieve. AFAIK the > if .. endif syntax used by automake is for conditionals only (see: > http://www.gnu.org/software/automake/manual/html_node/ > Conditionals.html) and there is nothing such as "ifdef". ifdef...endif is GNU make syntax. I found some old mail now, that tells me, that automake doesn't accept that syntax, although it doesn't need to process it. The ifdef...endif syntax would be interpreted by GNU make. Of course my example probably would need to be interpreted by automake too, because WIN32_EXTRA_LDFLAGS is set, before it gets extended. But to know that, automake would need to understand this syntax. However, what I wanted to do is not possible atm, so I restored the old Makefile code. Regards, Daniel
ifdef ... endif issue
Hi, I wanted to use this code in one of my Makefiles: ifdef WIN32_EXTRA_LDFLAGS WIN32_EXTRA_LDFLAGS += -export-symbols $(srcdir)/entities.def endif But that doesn't work. automake complains: src/plugin_entities/Makefile.am:22: WIN32_EXTRA_LDFLAGS must be set with `=' before using `+=' src/plugin_entities/Makefile.am:23: endif without if 1. Shouldn't automake stop complaining about setting WIN32_EXTRA_LDFLAGS first, when I test for its existence? 2. Why is automake complaining about the endif "without" if? The ifdef...endif condition is part of make and I know several Makefiles, that use it. Is it a bug in automake? Regards, Daniel
Re: Strictness
Am Samstag, den 11.08.2007, 17:33 +0100 schrieb Noah Slater: > > The reason for this is: > > ChangeLog: often mostly a duplicate of svn/cvs logs, seldom really used > > I agree about ChangeLog - there is no reason to be using this any more. There is. Changelogs are useful to follow the changes in a source. If you do not put this into VCS, developers have to run VCS diff and (r)log commands to know, what has been changed. I'm a big fan of file changelogs. Creating/updating it first is not very comfortable for developers. I further think, that many projects use the changelog entry as commit message, which is IMO different to the OPs opinion, that changelogs are the duplicate of the svn/cvs logs. The commit message is more a duplicate of the changelog entry. Of course, just my humble opinion. Regards, Daniel
Re: Adding extra rules to make
Am Donnerstag, den 21.06.2007, 13:56 +0200 schrieb [EMAIL PROTECTED]: > Hello, > > As part of the build process, I would like to convert text files to > binary files. They don't get installed, the files can be used later to > test the program. > > In particular, the input format is *.txt and the output format is *.bin. > > I've got it working, but I feel it's far from elegant. I want it to be > part of the distribution package, the .bin files to be generated by > the source .txt files but I don't want them to be installed anywhere. > > Thanks, > Jason. > > Makefile.am > SRC = 01_InvalidByte.txt \ > 02_CorruptedMsg.txt \ > 03_InvalidByte.txt \ > 04_InvalidByteAscii.txt \ > 05_BufferOverrun.txt > > # The rule: > # BIN = $(SRC:.txt=.bin) > # doesn't seem to work Works here (but see SUFFIXES). > BIN = 01_InvalidByte.bin \ > 02_CorruptedMsg.bin \ > 03_InvalidByte.bin \ > 04_InvalidByteAscii.bin \ > 05_BufferOverrun.bin > > CLEANFILES = $(BIN) > > EXTRA_DIST = $(SRC) pxxd.pl > > all: $(BIN) This should be `all-local:'. The all-target is automatically created by automake. > # When we 'make' we create generate the bin files > .txt.bin: > perl pxxd.pl $< $@ I guess, you further need a SUFFIXES = .txt .bin Then it works here. Regards, Daniel
Re: make distcheck and the /etc dir
Am Sonntag, den 10.06.2007, 09:01 +0200 schrieb Ralf Wildenhues: > * Daniel Leidert wrote on Mon, Jun 04, 2007 at 07:38:18PM CEST: > > Am Montag, den 04.06.2007, 15:56 +0200 schrieb Jason Curl: > > > > > ># Makefile.am for installing configuration data > > >etcdir=/etc/lx2005 > > > > This line misses a $(DESTDIR) to not break package builds and distcheck. > > No, it doesn't. > > > >etc_DATA = serlog.conf > > [snip] > > > The configuration that gets copied depends on the 'configure' script > > > setting the variable $(MACHINE). > > > > > > When I run 'make distcheck' it fails as it cannot install the files to > > > '/etc/lx2005'. I would very much like the location of the configuration > > > files to be independent of $(prefix) as the locations my project > > > searches are independent of where it was installed. > > > > No problem: But you should add the DESTDIR variable to hardcoded paths. > > Only in rules. You are right. I already found my mistake. Regards, Daniel
Re: Is including a custom dist-foo into distcheck impossible
Am Donnerstag, den 07.06.2007, 13:58 +0100 schrieb Noah Slater: > > I do something similar for building an nsis-based win32 installer: > > I will check this out tomorrow. Thanks. > > > Also, you may wish to reconsider whether it is wise to include a > > debian target/directory directly, or whether you might follow the > > usual convention for delivering debian source packages: > > Mine is a special case however as I will also be the Debian maintainer > for the native Debian package and so maintaining an > upstream/downstream source directory along with an orig.tar.gz does > not make a great deal of sense. Can you provide a link to your project? Are you using a special VCS? Regards, Daniel
Re: make distcheck and the /etc dir
Am Montag, den 04.06.2007, 22:15 +0100 schrieb Noah Slater: > > Sounds like my best solution would be to use the "sysconf_DATA" option. > > Any ideas how to take 'sysconfdir' and somehow import it into my program > > so it knows where the default configuration files are? > > Well, I use Python and I have a file called 'lib/foo/__init__.py.in' > that is has the following lines: [snip] > Now, when ./configure is run this file is generated and placed at > 'lib/foo/__init__.py' and hence is available to me a run-time with all > the user configured paths. > > If you are using C I believe the recommended way is to use a header > file with a bunch of defines that gets customised at ./configure time. Well, that has some limitations. It's possible, that you need to evaluate a variable with eval more than just once (e.g. $datadir needs at least two eval calls). People often use a loop to do this. IMHO it's easier to use DEFS instead here: DEFS += -DSYSCONFDIR=\"$(sysconfdir)\" -DPKGDATADIR=\"$(pkgdatadir)\" and don't use config.h for this. Regards, Daniel
Re: make distcheck and the /etc dir
Am Montag, den 04.06.2007, 15:56 +0200 schrieb Jason Curl:
> Hello,
>
> I have a project where the program expects the configuration files to be
> stored in '/etc/lx2005'. Appropriately, I've got such a Makefile.am:
>
># Makefile.am for installing configuration data
>etcdir=/etc/lx2005
This line misses a $(DESTDIR) to not break package builds and distcheck.
>etc_DATA = serlog.conf
[snip]
> The configuration that gets copied depends on the 'configure' script
> setting the variable $(MACHINE).
>
> When I run 'make distcheck' it fails as it cannot install the files to
> '/etc/lx2005'. I would very much like the location of the configuration
> files to be independent of $(prefix) as the locations my project
> searches are independent of where it was installed.
No problem: But you should add the DESTDIR variable to hardcoded paths.
If you use sysconfdir etc.pp, you don't need to add the DESTDIR variable
explicitly.
> Installing to my remote file system is easy enough and it works:
>make DESTDIR="/mnt/remotefs" install
And the configuration file then is inside /etc and not /mnt/remotefs?
Why? And BTW: That should be done using --prefix=/mnt/remotefs
--sysconfdir=/etc and not DESTDIR (IMHO). DESTDIR is used e.g. for
creating packages (e.g. Debian packages). With your usage of this
variable, you break the possibility to package your software, because it
will try to write to /etc in every case.
> How can I get 'make distcheck' to work with this configuration?
> Alternatively, I'm open for other ideas of implementation.
BTW: If you use
etcdir=${sysconfdir}
you can set
DISTCHECK_CONFIGURE_FLAGS = --sysconfdir=/etc
And if you want to make this the default, set it in your configure
script:
AC_SUBST([sysconfdir],[/etc])
However, you should carefully think about this. I personally would leave
it up to the user to choose a directory.
Regards, Daniel
Re: Problem with distribution of bin_SCRIPTS
Am Dienstag, den 29.05.2007, 09:58 +0100 schrieb Noah Slater: > In my package I would like to generate a script from a source file by > simply copying it and setting the executable bit. I do not need to > distribute the script though, only the source. > > No matter how hard I try I cannot get automake to work using the > following set-up: > > * The script source is distributed > * The script is NOT distributed but is generated from the source I guess then you want to use noinst_SCRIPTS or BUILT_SOURCES instead of bin_SCRIPTS. Regards, Daniel
Re: How do I get automake to create compressed man pages?
Am Mittwoch, den 18.04.2007, 00:46 -0500 schrieb Paul Elliott: > Excuse me if this is a faq but I can not easily find the asnwer. > > I have a Makefile.am that creates and installs a man page myprog.1 > > It says > > man1_MANS = myprog.1 > > The source is myprog.1. How do I make it create and install a compressed > man page version myprog.1.gz? What about: man1_MANS = myprog.1.gz %.1.gz : %.1 gzip $< -c > $@ ? Regards, Daniel
Re: Install library sources with automake
Am Samstag, den 24.03.2007, 23:27 +0300 schrieb Alexey Beshenov:
> Hi!
>
> At this time I have experience with Makefiles for real compiling only.
>
> Now I have my own library sources. They should be placed in directory of
> compiller include path, as well as documentation should be placed to the
> system documentation directory.
>
> If library is named foo and it's sources and documentation are in the `src'
> and `doc' directories, awful shell script is
>
> #!/bin/sh
>
> rm -rf /usr/include/foo
> mkdir /usr/include/foo
> cp -r src/* /usr/include/foo
>
> rm -rf /usr/share/doc/foo
> mkdir /usr/share/doc/foo
> cp -r doc/* /usr/share/doc/foo
>
> How can I write more flexible Makefile without fixed directory destinations
> and ability to uninstall everything?
>
> Cold you give me a quick recipe, please?
Check the _HEADERS primary. You can simply use this:
myheadersdir = $(includedir)/foo
myheaders_HEADERS = [list of header files]
This istalls all header files defined in the _HEADERs variable to
$(includedir)/mylib (the includedir variable is defined by
configure/autoconf).
For documentation you can use:
mydocsdir = $(docdir)
mydocs_DATA = [list of docs]
or smaller:
doc_DATA = [list of docs]
because docdir is defined by autoconf/configure. Note, that the docdir
variable (and also the --docdir configure option) were introduced with
autoconf 2.60 IIRC. To be compatible with older autoconf releases, you
can use:
if test -n "$docdir"; then
docdir="${datadir}/doc/${PACKAGE}"
AC_SUBST([docdir])
fi
HTH & regards,
Daniel
Re: automake does not install mkinstalldirs?
Am Montag, den 12.03.2007, 09:45 +0100 schrieb Stephane Bortzmeyer: > "automake --add-missing" installs what I want except mkinstalldirs: > > echoping/trunk/SRC % automake --add-missing > echoping/trunk/SRC % ls -l mkinstalldirs > ls: mkinstalldirs: No such file or directory > > Therefore, "make dist" fails. > > Of course, I can do a symlink myself but I wonder why does automake > ignores this file? > > automake 1.9.6 automake >= 1.8 prefers mkdir over mkinstalldirs if available (otherwise it uses AFAIK `install-sh -d' now) and doesn't copy/link mkinstalldirs anymore. You would have to copy it yourself, if you still need it. Regards, Daniel
Re: Questions...
Am Sonntag, den 11.02.2007, 23:24 -0300 schrieb Matías Alejandro
Torres:
[..]
> I figure out my two questions... almost, let's say I want to copy one
> whole directory recursively
>
> Makefile.am
>
> contactsdatadir = ${prefix}/share/applications/contacts
> contactsdata_DATA = \
> themes
$(prefix)/share/applications is a directory containing .desktop files
(freedesktop.org specification) under Linux. You don't want to install
anything else than .desktop files there. Are you looking for
$(prefix)/share/contacts or $(pkgdatadir) (if you want to install
architecture-independent package-specific data, which I guess you want)
or $(prefix)/share/icons (which is a themes-directory)?
> themes is that directory but when I try to install it it throws me :
>
> test -z "/usr/local/share/applications/contacts" || mkdir -p --
> "/usr/local/share/applications/contacts"
> /usr/bin/install -c -m 644 './themes'
> '/usr/local/share/applications/contacts/themes'
> /usr/bin/install: se omite el directorio `./themes'
> make[2]: *** [install-contactsdataDATA] Error 1
>
> So what do i need to do to copy that directory recursively? or else..
> what do i need to do to create the themes directory so i can copy
> individual files?
A simple approach is:
contactsdatadir = ${pkgdatadir}/themes
contactsdata_DATA = themes/*.*
if that directory does not contain any sub-directories. An alternative
and IMO the only way to recursively copy a whole directory (_without_
using Makefiles for every sub-directory) with sub-dirs is to write your
own small piece of code and put it into the install-data-local target in
your Makefile.am. Note, that your code should respect e.g. the DESTDIR
variable. AFAIK there is no macro for recursively copying a directory
(or I never found it :)).
Regards, Daniel
Re: warning about GNU make extension with automake 1.10
Am Sonntag, den 07.01.2007, 12:53 +0100 schrieb Thomas Porschberg: > I upgraded automake from 1.9.6 to 1.0 and get some > warnings about make-rules which are GNU make extensions. > I would like to remove the warnings. You can make them "disappear" using AM_INIT_AUTOMAKE([-Wno-portablity]) or AUTOMAKE_OPTIONS = -Wno-portability > One warning is about: > > %.cpp: %.h %.ui > $(UIC) -o $@ -i $^ > > gives > ... `%'-style pattern rules are a GNU make extension You could try a suffix rule SUFFIXES = .cpp .h .ui .h.cpp: $(UIC) -o $@ -i $^ $*.ui Shall work. Give it a try. > and another > > BUILT_SOURCES = \ > $(filter %.qm,$(TRANSLATIONS:%.ts=%.qm)) > > gives > > ... filter %.qm,$(TRANSLATIONS: non-POSIX variable name > ... (probably a GNU make extension) I think, $(filter ...) is not necessary here. $(TRANSLATIONS:%.ts=%.qm) should already do, what you want and only contain .qm files - except the case that $(TRANSLATIONS) contains files with extensions != .ts. In this case you can only avoid your filter by putting only files with .ts extension into the TRANSLATIONS variable (splitting the TRANSLATIONS variable into several variables). > Can someone give me an advice how to rewrite the make rules ? HTH Regards, Daniel
