Re: Extending Automake to build non-file objects?

On 06/14/2014 01:00 PM, Conrad Dean wrote: Hey! I have a project where I need to generate datasets that are not stored as flat files. I can use a CLI interface to generate them off of others and the same CLI to check when datasets were last modified. I think I want to use automake to describe

Extending Automake to build non-file objects?

Hey! I have a project where I need to generate datasets that are not stored as flat files. I can use a CLI interface to generate them off of others and the same CLI to check when datasets were last modified. I think I want to use automake to describe the relationships between datasets, and dete

Re: Extending automake rules

Hi Stefano. On 11/11/12 09:19, Stefano Lattarini wrote: Unfortunately, it is basically impossible to accomplish what you want with the current Automake. That is, most rules can only be overridden, not extended (and those which can, can be only in a limited, unflexible way). You might manage to

Re: Extending automake rules

HI Miguel. On 11/10/2012 12:46 PM, Miguel Guedes wrote: > There's one thing I would simply love to accomplish with Automake: > the ability to extend rules without overriding them. For instance, > how would one print a custom message in a specific format (i.e. > color) each time a source file is co

Extending automake rules

There's one thing I would simply love to accomplish with Automake: the ability to extend rules without overriding them. For instance, how would one print a custom message in a specific format (i.e. color) each time a source file is compiled and a binary linked? For instance, in a traditional M

Re: extending automake targets

On Monday 11 October 2010, Ralf Wildenhues wrote: > Hello Stefano, > > * Stefano Lattarini wrote on Fri, Oct 08, 2010 at 11:56:55AM CEST: > > On Friday 08 October 2010, Ralf Wildenhues wrote: > > > Can we also keep its discussion and its eventual addition separate, for > > > both user-defined and

Re: extending automake targets

Hello Stefano, * Stefano Lattarini wrote on Fri, Oct 08, 2010 at 11:56:55AM CEST: > On Friday 08 October 2010, Ralf Wildenhues wrote: > > Can we also keep its discussion and its eventual addition separate, for > > both user-defined and automake-defined recursive targets, please? > Not really, bec

extending automake targets (was: Re: Recursive targets for the user)

On Friday 08 October 2010, Ralf Wildenhues wrote: > Hello Stefano, > > * Stefano Lattarini wrote on Fri, Oct 08, 2010 at 02:46:58AM CEST: > > What I'd like to do is to allow the developers to extend the nonrecursive > > part of any recursive `foo' rule (be it user-defined or automake-defined) > >

extending automake: implicit rules and sufixes is not enought

I would like have Makefile.am like this : > #include $(top_srcdir)/m4/autotroll.mk > > noinst_LIBRARIES = libcutitdata.a > > libcutitdata_a_SOURCES = data.qrc.cpp > libcutitdata_a_QT_RESOURCE_TEMPLATE = data.qrc > > libcutitdata_a_CXXFLAGS = $(QT_CXXFLAGS) $(AM_CXXFLAGS) > libcutitdata_a_CPPFLAGS =

Re: extending automake

greatly benefit from this feature, considering they could teach automake > how to run these commands. Wait, the above example is about extending automake, but not about rules which produce multiple output files, right? For the above, I'd just use (assuming SUFFIXES has already been set)

Re: extending automake

On Thu, May 01, 2008 at 03:48:25PM -0400, Bob Rossi wrote: > On Wed, Apr 30, 2008 at 03:21:18PM +0200, Ralf Wildenhues wrote: > > * Bob Rossi wrote on Wed, Apr 30, 2008 at 02:59:11PM CEST: > > > You busy or thing the idea is no good? > > > > Busy. If you want to help, there are still unaddressed

Re: extending automake

On Wed, Apr 30, 2008 at 03:21:18PM +0200, Ralf Wildenhues wrote: > * Bob Rossi wrote on Wed, Apr 30, 2008 at 02:59:11PM CEST: > > You busy or thing the idea is no good? > > Busy. If you want to help, there are still unaddressed questions from >

Re: extending automake

* Bob Rossi wrote on Wed, Apr 30, 2008 at 02:59:11PM CEST: > You busy or thing the idea is no good? Busy. If you want to help, there are still unaddressed questions from (even if the above notation is not adopted, it

Re: extending automake

On Fri, Apr 25, 2008 at 09:19:58AM -0400, Bob Rossi wrote: > On Fri, Apr 25, 2008 at 06:54:08AM +0200, Ralf Wildenhues wrote: > > * Bob Rossi wrote on Fri, Apr 25, 2008 at 03:41:20AM CEST: > > > On Sat, Apr 19, 2008 at 01:22:29PM -0400, Bob Rossi wrote: > > > > They generate files during build time

Re: extending automake

On Fri, Apr 25, 2008 at 06:54:08AM +0200, Ralf Wildenhues wrote: > * Bob Rossi wrote on Fri, Apr 25, 2008 at 03:41:20AM CEST: > > On Sat, Apr 19, 2008 at 01:22:29PM -0400, Bob Rossi wrote: > > > They generate files during build time, and modify BUILT_SOURCES... > > > > > > In fact, think of the bi

Re: extending automake

* Bob Rossi wrote on Fri, Apr 25, 2008 at 03:41:20AM CEST: > On Sat, Apr 19, 2008 at 01:22:29PM -0400, Bob Rossi wrote: > > They generate files during build time, and modify BUILT_SOURCES... > > > > In fact, think of the bison or flex extension (adding .y or .l files to > > the _SOURCES variable)

Re: extending automake

On Sat, Apr 19, 2008 at 01:22:29PM -0400, Bob Rossi wrote: > On Sat, Apr 19, 2008 at 05:51:35PM +0200, Ralf Wildenhues wrote: > > * Brian Dessent wrote on Sat, Apr 19, 2008 at 04:45:54PM CEST: > > > It would be equally difficult as in the case with MULTITARGETS and > > > foo_{TARGETS,SOURCES,COMMAN

Re: extending automake

On Sat, 19 Apr 2008, Bob Rossi wrote: Unfortunately, both of you are talking over my head. I don't have all that much experience with make. However, I've worked on a lot of open source projects, and all of them do this common task. They generate files during build time, and modify BUILT_SOURCES

Re: extending automake

On Sat, Apr 19, 2008 at 05:51:35PM +0200, Ralf Wildenhues wrote: > * Brian Dessent wrote on Sat, Apr 19, 2008 at 04:45:54PM CEST: > > It would be equally difficult as in the case with MULTITARGETS and > > foo_{TARGETS,SOURCES,COMMAND}, no? > > Well, the first step in exploring this further would b

Re: extending automake

* Brian Dessent wrote on Sat, Apr 19, 2008 at 04:45:54PM CEST: > Ralf Wildenhues wrote: > > > Do you mean that, given that keyword, all rules of the form > > target1 target2 : prereq ... > > command ... > > > > should be rewritten to be a multiple-target rule? > > Yeah. > > > Ugh. Th

Re: extending automake

Ralf Wildenhues wrote: > Do you mean that, given that keyword, all rules of the form > target1 target2 : prereq ... > command ... > > should be rewritten to be a multiple-target rule? Yeah. > Ugh. That would > violate the "input appears in output" quite heavily. Sure, but that's alr

Re: extending automake

* Brian Dessent wrote on Sat, Apr 19, 2008 at 03:59:19PM CEST: > Ralf Wildenhues wrote: > > > > The MULTITARGETS and foo_{TARGETS,SOURCES,COMMAND} syntax that you came > up with is certainly in line with the Automake wa

Re: extending automake

Ralf Wildenhues wrote: > This thread has some ideas: > > > If you (or anybody) finds the above useful, and think the setup is > general enough for several use cases, we can think about how to > integrate it into Automa

Re: extending automake

* Brian Dessent wrote on Sat, Apr 19, 2008 at 02:42:57PM CEST: > > That brings up the next logical point, can anyone comment on the > feasibility of some kind of generalized "tool X reads A and outputs Y > and Z" construct to help solve the "tools generating multiple outputs" > case without having

Re: extending automake

Ralf Wildenhues wrote: > Well, this scheme can easily be generalized to one stamp file per set of > output files, no? And then it parallelizes well, too. Yes, I suppose if you named the stamp with a filename derivable from that of the .xml filename you could generalize this without having to wri

Re: extending automake

Bob Rossi wrote: > verbose). Why are you not sure this is a good idea? I sort of feel like there are "workspaces", the configure area and the make area. This parallels the idea that there are configure-substituted variables and make-substituted variables, the latter can be changed/overridden whe

Re: extending automake

On Fri, Apr 18, 2008 at 09:23:59PM -0700, Brian Dessent wrote: > Bob Rossi wrote: > > I would like to automake this by writing a wrapper like, > > AM_GEN(foo.xml) > > I'm not sure that configure-time is where you want to deal with this. Wow, your answer is great, and shows how little I actually

Re: extending automake

Hi Bob, Brian, * Brian Dessent wrote on Sat, Apr 19, 2008 at 06:23:59AM CEST: > Method B, not GNU make specific, using a single witness stamp along the > lines of what is suggested in the manual: [...] > pyxml-stamp: $(PYXMLFILES) > @rm -f pyxml-tmp > @touch pyxml-tmp > (set -e;

Re: extending automake

Bob Rossi wrote: > EXTRA_DIST = foo.xml > > BUILT_SOURCES = foo.h foo.cc > > foo.h foo.cc: $(srcdir)/foo.xml $(top_srcdir)/gen.py > python $(abs_top_srcdir)/gen.py $(srcdir)/foo.xml This is not good. When you write: target1 target2: prereq recipe It is really shorthand for: target

extending automake

Hi, Up until now, I've just used the canned macros that automake provides. However, I'm wondering if it has a way that I can extend it. I basically have an xml file, and a python script, that generates a header and a source file. I write this in multiple spots in my Makefile.am EXTRA_DIST = foo.

Re: extending automake support for exotic languages

>>> "Guillaume" == Guillaume Rousse <[EMAIL PROTECTED]> writes: Guillaume> Hello. Guillaume> A colleague of mine developped a custom language for Guillaume> natural language processing, called DyALog Guillaume> (http://atoll.inria.fr/~clerger/work.html#DyALog). In Guillaume> order to ease mo

extending automake support for exotic languages

Hello. A colleague of mine developped a custom language for natural language processing, called DyALog (http://atoll.inria.fr/~clerger/work.html#DyALog). In order to ease module development, he also extended automake to support this language. However, he is currently maintaining it as a patch a

Re: Extending automake

If somebody can take me off this list or tell me how I can do it myself I'd be rather happy. -mario - Original Message - From: "Faschingbauer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, August 03, 2004 3:30 P

Re: Extending automake

> "Chris" == Chris Lee <[EMAIL PROTECTED]> writes: Chris> Hi, all. Chris> In KDE, currently, we have a custom perl script called am_edit which Chris> does a bunch of voodoo to support some custom keywords that we use in Chris> KDE-ized Makefile.am files. Chris> I personally am on a vendetta

Re: Extending automake

Hi, On Sun, 01 Aug 2004 21:47:36 +0200, Chris Lee wrote: ... > Even removing the ability to provide the foo_METASOURCES = AUTO would be > fine with me if I could at least do 'foo_METASOURCES = foo.moc bar.moc' > but at the moment I still don't quite grok how to do that. In such case you can use:

Re: Extending automake

On Sun, Aug 01, 2004 at 03:47:36PM -0400, Chris Lee wrote: > Even removing the ability to provide the foo_METASOURCES = AUTO would be > fine with me if I could at least do 'foo_METASOURCES = foo.moc bar.moc' > but at the moment I still don't quite grok how to do that. I generally do this sort of t

Re: Extending automake

have accumulated as our build system, and I'd like to do it in a way that uses the standard mechanisms provided for extending automake, while still providing backwards compatibility if at all possible. I'm just terribly confused at the moment by the .am files in my /usr/share/automake directory,

Extending automake

Hi, all. In KDE, currently, we have a custom perl script called am_edit which does a bunch of voodoo to support some custom keywords that we use in KDE-ized Makefile.am files. I personally am on a vendetta against our existing crufty build system, and as part of that I'm trying to figure out ho

extending Automake with a custom primary

Hi, I want to extend Automake with my own primary. I am writing to ask if Automake can be customized this way. I would like to write in Automake.am: VPSRC = @VPSRC@ noinst_VPBUILD = vorpal_ser vorpal_par vorpal_ser_CONFFLAGS = --disable-mpi vorpal_par_CONFFLAGS = --enable-mpi My primary would

extending Automake with a custom primary

Hi, I want to extend Automake with my own primary. I am writing to ask if Automake can be customized this way. I would like to write in Automake.am: VPSRC = @VPSRC@ noinst_VPBUILD = vorpal_ser vorpal_par vorpal_ser_CONFFLAGS = --disable-mpi vorpal_par_CONFFLAGS = --enable-mpi My primary would

Re: Extending automake syntax

On 1 Jan 2002, Tom Tromey wrote: > Is SpeciaLib GNU software? > One of automake's goals is to interoperate well with GNU software. SpeciaLib doesn't quite exist yet except as pieces pulled from other projects of mine, mostly libcodec (see codecs.org for all this stuff anyway). I intend to make o

Re: Extending automake syntax

> "Erik" == Erik Walthinsen <[EMAIL PROTECTED]> writes: >> You can't accomplish what you want without hacking automake itself. >> It seems like something specific to your project. Is that the case? Erik> Yup. Well, sorta. "SpeciaLib" is a library and a set of tools Erik> for creating spec

Re: Extending automake syntax

On 31 Dec 2001, Tom Tromey wrote: > Erik> lib_SLLIBRARIES = libaverage.sl > > Erik> libaverage_sl_SOURCES = \ > Erik> average_c.c \ > Erik> average_mmx.c \ > Erik> average_sse.c \ > Erik> average_altivec.c > > You can't accom

Re: Extending automake syntax

> "Erik" == Erik Walthinsen <[EMAIL PROTECTED]> writes: Sorry for the delay in my reply. Erik> I'm working on a project where I want to create a new class of Erik> vars for automake, which will include rules which will turn into Erik> both generated source targets, and normal libtool libs.

Extending automake syntax

I'm working on a project where I want to create a new class of vars for automake, which will include rules which will turn into both generated source targets, and normal libtool libs. For example: lib_SLLIBRARIES = libaverage.sl libaverage_sl_SOURCES = \ average_c.c