On a related note, does the restriction of not using shell functions in
autoconf macros still remain, or have the OSs with such shells now gone
the way of SunOS 4.x?
Cheers,
Alex.
--
Alex Hornby <[EMAIL PROTECTED]>
Hi,
As part of my project I have some suffix rules to produce built sources
from which I can produce automatic dependency information.
My question is - is it possible to get automake to take these user
defined auto dependencies into consideration?
What I'd envisage is being able to set a user va
On Thu, 2002-11-14 at 19:18, Sebastian Huber wrote:
> Hello,
> SWIG generates a Python module for me. This works fine with Automake 1.7
> except that a 'make distcheck' fails:
>
> No files given to ../config/py-compile
> make[2]: *** [install-nodist_pythonPYTHON] Error 1
>
> I suppose this is be
On Thu, 2002-08-29 at 10:57, Akim Demaille wrote:
>
> | There are compilers which don't accept `.cc' but need `.cpp' for C++
> | files. Among them are z/OS (by default) and various compilers for
> | MS-DOS and Windows. What about support for a CXXEXT variable? It is
> | quite easy to add a rul
On Mon, 2002-05-06 at 06:30, Tom Tromey wrote:
> Nowadays we could probably implement pattern rules purely in automake.
> Back in the old days we didn't have the machinery to allow this.
> Automake itself was too primitive. But now it would be more possible,
> if someone were motivated. Maybe th
On Mon, 2002-04-29 at 12:44, [EMAIL PROTECTED]
wrote:
> alex> Could you check if the automake 1.6.x docs make the same reference to
> alex> "GNU make" instead of just make when talking about suffix rules?
>
> No, they don't.
Great, so no doco patch needed :)
> So this is enough if you have a s
On Mon, 2002-04-29 at 12:24, [EMAIL PROTECTED]
wrote:
> alex> I think the recommended way is to add suffix rules to produce the built
> alex> sources, not edit the Makefile.ins.
>
> But is this really portable ? I looked at automake 1.4 info pages, and it tells
> something about GNU make:
Suffi
On Mon, 2002-04-29 at 10:24, [EMAIL PROTECTED]
wrote:
> It is common style to generate c/cpp source files from some meta-languages.
> Examples are lex, yacc, QT's moc, swig, and probably many other tools. AFAIK
> there is currently no way to handle such files in automake and the recommended
> w
On Tue, 2002-03-05 at 21:17, Tom Tromey wrote:
> >>>>> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
>
> Alex> I'm trying to update some old Makefile.am's to the CVS automake. Its
> Alex> going well except I can't see a way to o
Hi,
I'm trying to update some old Makefile.am's to the CVS automake. Its
going well except I can't see a way to override a variable value, as I
get:
config/sqlstatic.am:20: sqldemoperl_DATA multiply defined in condition
TRUE
sqldemoperl_DATA (User, where = config/sqlstatic.am:20) =
{
TRU
On Thu, 2002-01-31 at 06:41, Bob Proulx wrote:
> > It is possible to set up moderation. Actually, moderation is a wrong
> > word. The only responsibility of the moderator show be preventing spam.
>
> I help moderate a few of the GNU lists which are moderated solely to
> prevent spam and I can
On Wed, 2001-11-07 at 05:59, Tom Tromey wrote:
> > "Alexandre" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
>
> >> SUFFIXES = .k
>
> Alexandre> (This is superfluous, Automake will infer it from the .k.o
> Alexandre> rule below)
>
> Is it still documented as being required?
>
> Tom
On Thu, 2001-10-25 at 10:57, Alexandre Duret-Lutz wrote:
> >>> "Simon" == Simon Perkins <[EMAIL PROTECTED]> writes:
>
> [...]
>
> Simon> The obvious solution is to use the -C option to install
> Simon> which will only copy header files that have actually
> Simon> changed since the last instal
On Mon, 2001-10-08 at 15:50, Kyle F. Downey wrote:
> It's actually even more complicated.
>
> CORBA support is a huge mess similar to the diversity of UNIX flavors
> that led to the creation of the autotools suite in the first place. Proper
> CORBA support in autotools would require a new subsys
In the CVS head I'm getting automake warnings if I override the value
of a variable.
I have a common.am which is included at the top of all my Makefile.am
files which sets the value for "PERLINST" to a sensible default, but
occasionally one of the directories needs a different value, so I
overr
Hi,
I'm updating my 6 month old automake tree to try and get the patsubst
and built source patches going again, and have noticed that all the
newer code is in true GNU indent style rather than the earlier
approximation.
e.g. new style
if (/AM_PATH_PYTHON/)
{
$seen_
Pavel Roskin writes:
>
> > - ($from = $2) =~ s/(\W)/\\$1/g;
> > + ($from = $2) =~ s/(\W)/$1/g;
>
> I don't understrand this. This change will affect the traditional rules as
> well. It should probably be a separate patch if it fixes a separate issue.
> You may even need
@@ -0,0 +1,15 @@
+2001-02-18 Alex Hornby <[EMAIL PROTECTED]>
+
+ * automake.in (expand_contents): add new function to perform
+ the patsubst expansion
+ (value_to_list): add support for patsubst style variable
+ substitution.
+ (read_main_am_file): call expand_co
Hi Pavel,
Thanks for your comments, I'll put together a new patch taking them
into account.
Removing the new command line option will simplify things and get rid
of the need for the second call to handle_options.
Regards,
Alex.
.
Regards,
Alex Hornby
diff -r -P -u --exclude-from=/tmp/diff_exclude.9118 automake-cvs/ChangeLog.patsubst
automake-patsubst/ChangeLog.patsubst
--- automake-cvs/ChangeLog.patsubst Thu Jan 1 01:00:00 1970
+++ automake-patsubst/ChangeLog.patsubstSun Feb 11 19:55:33 2001
@@ -0,0 +1,11
Alexandre Oliva writes:
> On Oct 27, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> > Yep, by default Automake must not let the users do nonportable
> > things.
>
> I tend to agree. But I wouldn't say `must not', I'd say `should not'.
What is the policy regarding changes to non-porta
Akim Demaille writes:
>
> Sorry, I'm confused, and the documentation snippet didn't really
> enlighten me :(
>
Hi Akim,
The reasoning was fairly tortured :)
To document the patsubst internal change I had to invent a contrived
example so that the user could see the expansion. That example
Wed Oct 25 15:41:28 2000
@@ -0,0 +1,5 @@
+2000-10-25 Alex Hornby <[EMAIL PROTECTED]>
+
+ * automake.in (value_to_list): Add support for patsubst
+ style variable substitution.
+
diff -r -P -u automake/NEWS.entry automake-patsubst/NEWS.entry
--- automake/NEWS.entry Thu Jan
Alex.
diff -r -P -u automake/ChangeLog.entry automake-patsubst/ChangeLog.entry
--- automake/ChangeLog.entryThu Jan 1 01:00:00 1970
+++ automake-patsubst/ChangeLog.entry Wed Oct 25 14:16:08 2000
@@ -0,0 +1,5 @@
+2000-10-25 Alex Hornby <[EMAIL PROTECTED]>
+
+ * automake.in (value_t
Akim Demaille writes:
>
> Hi Alex,
>
> | I could split it into four or five patches (that would be
> | incrementally applied) e.g:
> |
> | 1) gcc style cpp depcomp
> | 2) patsubst style variable substitution
> | 3) suffix supplied dependencies
> | 4) improved suffix rule recognition
Tom Tromey writes:
> >>>>> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
>
> Alex> Here is the first broken out part of my parallel built sources
> Alex> patch, which I agreed to split up and resubmit back in the midst
> Alex>
nstall to locations other that bin_ and lib_ then a larger fix
is necessary, but this should fix the 90% case.
2000-09-05 Alex Hornby <[EMAIL PROTECTED]>
* automake.in (handle_merge_targets): Allow parallel install
with forced relink
Index: automake.in
===
Akim,
Here is the first broken out part of my parallel built sources patch,
which I agreed to split up and resubmit back in the midst of time. I
hope you still have the time to review these.
Regards,
Alex.
Here's the ChangeLog entry
2000-06-21 Alex Hornby <[EMAIL P
Tom Tromey writes:
> Alex, did you file the papers with the FSF? I don't recall seeing a
> message from them. The patches can't go in until the paperwork
> clears. If you did this in the past and I forgot, please accept my
> apologies.
>
I've sent them in... but I've not heard anything b
Akim Demaille writes:
> >>>>> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
>
> Alex> If I was to do this, would someone with CVS access consider
> Alex> applying them in a timely manner? I suspect I might go mad
> Alex> tryi
Akim Demaille writes:
> Hi Alex,
>
> I'm no Automake maintainer, so you may just forget everything I will
> say :)
>
> I think your patch addresses a very interesting issue, and it would be
> great to apply it, but it's getting very big. If there are
> independent chunks in it, you shou
Tom Tromey writes:
> Dean> I am looking for a way to include extra rules in every
> Dean> Makefile.in that automake generates.
>
> The typical way is to make a "Makefile.include" and then include it
> from each Makefile.am.
>
> Dean> %.s: %.c
>
> Note that "%" rules are not portable.
ntry
automake-anvil/Changelog.entry
--- automake/Changelog.entryThu Jan 1 01:00:00 1970
+++ automake-anvil/Changelog.entry Thu Jul 6 13:35:18 2000
@@ -0,0 +1,34 @@
+2000-06-21 Alex Hornby <[EMAIL PROTECTED]>
+
+ * automake.in (handle_source_transform): Added support fo
Sascha Demetrio writes:
>
> I think the more interesting question is: Does ``make -q'' the same thing
> on all platforms? I've seen -q for ``Quiet mode'' and -q for ``Question
> mode'' (i.e. check if the target is up-to-date without building it).
>
> solong,
> Sascha
All makes I've
Alexandre Oliva writes:
> On Jun 30, 2000, Alex Hornby <[EMAIL PROTECTED]> wrote:
>
> > Is make -q portable?
>
> I don't think so.
>
It is present on GNU Make, Solaris 2.6 make and HP-UX 10.20 make (all
the platforms I currently have access to). Could you
Is make -q portable? If so I could speed up my parallel built source
patch somewhat.
Alex.
Alexandre Oliva writes:
> If the extra newline will be in the actual output, it will break some
> stupid `make's that will go nuts if they find an empty line after a
> backslash.
>
I didn't know about that :) Here's a new version of depcomp patch that
avoids it.
Alex.
Index: depcomp
==
Here's a patch to the depcomp cpp method that:
* makes its output more similar to the gcc method
* removes trailing line numbers produced by cpp
I wasn't convinced that the old method actually gave make the right
dependencies, so I copied the gcc format which is easier to read and
it wider use.
Tom Tromey writes:
> Alex> Please try it out. If it doesn't break normal automake usage I'd
> Alex> like to have this considered for CVS.
>
> Just to warn you, it is likely to be some time before I can look at
> this. Bogus. Also, if it does go in, you will need to fill out the
> paperwor
-anvil/CVS
diff -u --unidirectional-new-file automake/ChangeLog automake-anvil/ChangeLog
--- automake/ChangeLog Mon Jun 19 23:30:34 2000
+++ automake-anvil/ChangeLogWed Jun 21 16:12:52 2000
@@ -1,3 +1,38 @@
+2000-06-21 Alex Hornby <[EMAIL PROTECTED]>
+
+
53:46
@@ -1,3 +1,27 @@
+2000-06-19 Alex Hornby <[EMAIL PROTECTED]>
+
+ * automake.in (handle_source_transform): Added support for per
+ target built source detection using suffix rules. This allows
+ projects with built sources to build with make -j without prior
+
Heres a script that I use to generate configure.in from a template
file with @Makefiles@ in AC_OUTPUT. This is so that developers can add
directories without having to change configure.in.
Is this of use to anyone? If you have a better/simpler version let me
know, as this was a quick hack. I thi
Ossama Othman writes:
> Hi Alex,
>
> On Wed, May 31, 2000 at 07:01:52PM +0100, Alex Hornby wrote:
> > Apart from the obvious difficultly of multi ORB setup etc, to keep
> > clients small it is often desirable to put the IDL client stubs in a
> > library, keep
Tom Tromey writes:
> >>>>> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
>
> Alex> Is there already an expand_make_variable() type function?
>
> Yes. You can use variable_value_as_list in automake to do this. But
> really you&#x
( I've moved this to the automake list only. )
I now have my dependency files being generated in .deps using depcomp.
I've used a new filename .deps/$*.Pcpp to hold these.
The remaining problem is to get automake to generate include's for
them and list them in DEP_FILES. I suspect this will re
As IDL files use standard C preprocessor syntax for dependent
inclusion, is it not possible to wrap the idl compile in depcomp?
My IDL build rules are already structured as suffix rules, with a
small wrapper script around the IDL compiler that uses lockfile(1) to
prevent two targets (e.g. client
Tom Tromey writes:
> [snip]
>
> I looked at automake.in. I don't understand why it doesn't work for
> you right now. The existing lang_cxx_rewrite looks right to me.
>
> Tom
I now see what my problem was. When I first tried c++ subdir objects I
hadn't got the subdir-objects option set :
--- 1,11
+ 2000-04-11 Alex Hornby <[EMAIL PROTECTED]>
+
+ * m4/minuso.m4 (AM_PROG_CXX_C_O): new function
+
+ * automake.in (seen_cxx_c_o): new global
+ (lang_cxx_rewrite): added subdir source support
+ (scan_one_configure_file): likewise
+
2000-04-05 Tom
Tom Tromey writes:
> >>>>> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
>
> Alex> I'm using CVS automake and have source files in sub directories of my
> Alex> project like so:
>
> Alex> That would be fine, but AFAICT th
I'm using CVS automake and have source files in sub directories of my
project like so:
./forward_idl/Foo/Bar.cpp
In my Makefile.am I list them
fooserver_SOURCES = forward_idl/Foo/Bar.cpp
In the generated Makefile I see
fooserver_OBJECTS = Bar_c.o
Bar_c.o: forward_idl/Foo/Bar_c.cpp
That wo
Alexandre/Tom,
If no one else is working on it I'm interested in implementing this
hook functionality. Parallel builds will save me a significant amount
of time.
Do you have any hints before I dive in? Is the current CVS head a good
starting point?
TIA
Alex.
Alexandre Oliva writes:
> On Mar
Tom Tromey writes:
> >>>>> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
>
> >> How about just creating standard Makefile dependencies?
> >>
> >> Foo_impl.o: Foo_s.hh Foo_c.hh Foo_s.cpp Foo_c.cpp
> >> Foo_impl
Alexandre Oliva writes:
> On Mar 21, 2000, Alex Hornby <[EMAIL PROTECTED]> wrote:
>
> > I would like to ensure that Foo_[sc].hh and Foo_[sc].cpp are present
> > before Foo_impl.cpp is built for the first time.
>
> How about just creating standard Makefile d
When I perform a parallel (MAKE="gmake -j4") build for derived
sources, the derived sources are not always produced before the non
derived sources are built. This is a problem as Foo_real.cpp includes
Foo_derived.h.
Perhaps this is a make problem? I'm using gnu make 3.76.1 and automake
1.4.
Ho
Alexandre Oliva writes:
> On Mar 20, 2000, Alex Hornby <[EMAIL PROTECTED]> wrote:
>
> > Is is possible to set a top level LDFLAG in my Makefile.am to turn off
> > rpath for binaries linked against libtool shared libraries?
>
> I don't think so. There&
Is is possible to set a top level LDFLAG in my Makefile.am to turn off
rpath for binaries linked against libtool shared libraries?
If so what is the magic incarnation?
TIA
Alex.
OKUJI Yoshinori writes:
> Automake requires some helper scripts such as `depcomp', but there
> is an inconsistency. The documentation tells me that they are put in
> the top directory or the source directory. However, while `depcomp' is
> required in the source directory by automake, the `Ma
57 matches
Mail list logo
