RE: How to force a compilation ?
-Original Message- From: BERTRAND Joël [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 12:51 PM To: [EMAIL PROTECTED] Subject: Re: How to force a compilation ? Alexandre Duret-Lutz wrote: bj == BERTRAND Joël [EMAIL PROTECTED] writes: [...] bj It works fine. But, when I run make, a file named rpl.c must bj be recompiled. How can I do that ? What do you mean? If rpl.c must be compiled as rpl.o, just list rpl.c in the relevant *_SOURCES variable of your Makefile.am. rpl.o is built from rpl.c and rpl.h. But I would recompile this file when make is done (even if rpl.o is up to date, because the gcc command line contains -Ddate=... which changes.). Perhaps something on the line of: rpl.c: always always: addedd to your makefile? HTH Bernard Bernard Dautrevaux Microprocess Ingenierie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel:+33 (0) 1 47 68 80 80 Fax:+33 (0) 1 47 88 97 85 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: More an autopackage
-Original Message- From: Derek R. Price [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 10:36 PM To: [EMAIL PROTECTED] Cc: Geoffrey Wossum; [EMAIL PROTECTED] Subject: Re: More an autopackage Tom Tromey wrote: Unfortunately, I don't think it is that easy. First, Makefile.am contents can be conditional on the particular configuration. That is why you really want to deal with the post-configuration package (using `make') and not Makefile.am. Second, the more complex post-install scripts are generated by automake itself. For instance, take a look at the hair required to install an info page. It would be a pain for developers to have to insert this code by hand (if they even know it exists). Good point, but the general design I pointed out should still hold. Only the generated Makefile would be the source for the data needed for spec file generation rather than the Makefile.am, whether that's passed in or scanned. The pre/post install hair should be scannable from the Makefile as well, whether that's for a shared library or info. The spec file source would want room for install hooks as well, still. That way instructions for, say, taking a daemon down and up again could be inserted before automake acquires a daemon target. I think this need to depend on the configure-generated Makefile will have a very constraining effect on the implementation language: this precludes using ANYTHING that's not installed standard on any of the expected target OSes... That's exactly why configure generates sh-scripts and why libtool IS a shell script. You can use GNU m4 or PERL in autoconf and automake, as these are maintainer-only tools. If autopackage is a package-installer tool (i.e. a native package front-end) the choice of implementation language is almost restricted to "/bin/sh" or "/bin/sh" and probably "/bin/sh" :-) Just a thought, hoping to be wrong, Bernard ------------ Bernard Dautrevaux Microprocess Ingenierie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel:+33 (0) 1 47 68 80 80 Fax:+33 (0) 1 47 88 97 85 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: libs in subdirs
-Original Message- From: Bryan VanDeVen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 21, 2000 6:26 PM To: [EMAIL PROTECTED] Subject: libs in subdirs I think this has been coverered for shlibs but I culd not find anything for static libs... is there ary way (without libtool at the present) to build static convenience libs and then have them all combined in a top level directory? For instance /somelib /somelib/dbdbv /somelib/gdemv so there are source files in all three directories, and we would like to eventually combine all the object files into "libsomelib.a" we tried just listing all the sources in the top level makefile.am, but automake does not like having any sources in subdirectories it seems. So, if we just build libdbdbv.a and libgdemv.a in their respective directories with their own makefile.am's, is there a way to merge them together with the top level objects into one "libsomelib.a" ? What about a rule like: libsomelib.a: dbdv/libdbdbv.a gdem/libgdemv.a rm -rf libsomelib.temp mkdir -p libsomelib.temp cd libsomelib.temp $(AR) x ../dbdv/libdbdbv.a cd libsomelib.temp $(AR) x ../gdem/libgdemv.a cd libsomelib.temp $(AR) $(ARFLAGS) ../libsomelib.a *.o $(RANLIB) libsomelib.a rm -rf libsomelib.temp I know this is not so elegant, but it should work :-) HTH Bernard -------- Bernard Dautrevaux Microprocess Ingenierie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel:+33 (0) 1 47 68 80 80 Fax:+33 (0) 1 47 88 97 85 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
[patch] Changes to automake to properly update read-only source files
Hi there,
Installing automake in an environment where all my source files are
read-only, I get some small problems as automake expect in a lot of cases to
be able to overwrite some of the distributed files that I get read-only in
my environment (as they are in fact symbolic links to shared sources).
I thus had to change a few things in automake.
-
in "automake.in:"
=
The rule to generate aclocal.m4 must ensure that it can overwrite it, so I
rename the original aclocal.m4 as aclocal.m4.bak and re-create a writable
version of aclocal.m4 by using "cat" from the backup file.
When regenerating Makefile.in I use the same trick to ensure that
Makefile.in can be written, while creating a backup file.
in "remake.am":
===
I again take care to be able to write configure before calling autoconf,
although I've also submitted a patch to remove configure just before
re-creating it :-)
in "sanity.m4":
===
I just remove "conftestfile" before creating it.
in "texi-vers.am":
==
I remove both the version file and the time stamp just before creating them.
in "subdir4.test":
==
I removed "depcomp" before touching it; I'm not sure why this is done at all
as "defs" already copies $srcdir/depcomp in the test directory (and this
file is then read-only here). Perhaps one may just not touch the local
depcomp file? I had anyway to do something as otherwise the test failed and
prevent automatically installing on all my machines.
in "header.m4":
===
Just by security I removed the various stamp files before creating them, but
I do not put this in tha patch below for two reasons:
I'm not sure the stamp files are distributed; if they are'nt then removing
them should never be needed (only distributed files are usually found
read-only). (BTW there is also a java class.$dir.stamp file I consider in
automake.in; I don't remove it because I think it will not be distributed,
but I can't check as I do not yet have automake'd any java package).
After doing that I looked at the generated code (in config.status) and don't
understand at all what it does :-(, so I prefer not to change anything. My
main concern is that "$am_file" in the second argument to AC_OUTPUT_COMMANDS
seem to be expanded by configure, while the for loop is executed only by
config.status (and then am_file is only given a value in config.status, not
in configure)...
Any hint on this code would be welcome, even if it is just out of curiosity
:-)
To solve the first points, I propose the following patch against
CVS-automake:
Changelog:
--8
--
2000-09-12 Bernard Dautrevaux [EMAIL PROTECTED]
* automake.in: make a backup and a writable copy of aclocal.m4
before
calling aclocal; idem for Makefile.in before calling automake
* remake.am: make a backup and a writable copy of configure before
calling autoconf
* sanity.m4: remove conftestfile before creating it, in case it is
read-only
* texi-vers.am: remove both version.texi and the stamp file before
creating them
* subdir4.test: remove the "depcomp" copied by "defs" befroe
touching it, in
case it is read-only.
--8
--
The patch:
--8
--
*** old/automake.in 2000/09/11 11:26:14 1.1.1.3
--- new/automake.in 2000/09/11 17:41:52
***
*** 3196,3205
pretty_print_rule ("\$(ACLOCAL_M4):", "\t\t", @ac_deps);
!
! $output_rules .= ("\t"
! . 'cd $(srcdir) $(ACLOCAL)'
! . (variable_defined ('ACLOCAL_AMFLAGS')
? ' $(ACLOCAL_AMFLAGS)' : '')
! . "\n");
}
}
--- 3196,3210
pretty_print_rule ("\$(ACLOCAL_M4):", "\t\t", @ac_deps);
!
! $output_rules .= ( "\tif test -r \$(ACLOCAL_M4); then \\\n"
! . "\trm -f \$(ACLOCAL_M4).bak; \\\n"
! . "\tmv \$(ACLOCAL_M4) \$(ACLOCAL_M4).bak
\\\n"
! . "\tcat \$(ACLOCAL_M4).bak
\$(ACLOCAL_M4); \\\n"
! . "\tfi\n"
! . "\tcd \$(srcdir) \\\n"
! . "\t\$(ACLOCAL)"
! . (variable_defined ('ACLOCAL_AMFLAGS')
? ' $(ACLOCAL_AMFLAGS)' : '')
!
RE: [patch] new depcomp sxc method
-Original Message- From: Alexandre Oliva [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2000 7:23 PM To: Bernard Dautrevaux Cc: [EMAIL PROTECTED] Subject: Re: [patch] new depcomp "sxc" method On Sep 6, 2000, Bernard Dautrevaux [EMAIL PROTECTED] wrote: This patch is quite simple as the preprocessor is able to generate directly the correct dependency file with dummy dependencies for all included files to avoid the "deleted header file" syndrom. It would be nice to note this fact as a comment in the script, otherwise someone unaware of this fact might think of ``fixing'' it later on :-). So what about: The Changelog: 2000-09-07 Bernard Dautrevaux [EMAIL PROTECTED] * depcomp: Add an "sxc" method for dependencies generation The patch: *** depcomp.old 2000/09/04 17:48:20 --- depcomp 2000/09/06 15:20:57 *** *** 65,68 --- 65,73 ;; + sxc) + # sxc already takes care of the 'deleted header file' problem by itself + exec "$@" -:pied="$depfile" + ;; + sgi) if "$@" -MDupdate "$tmpdepfile"; then : Bernard Dautrevaux Microprocess Ingenierie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel:+33 (0) 1 47 68 80 80 Fax:+33 (0) 1 47 88 97 85 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
[patch] new depcomp sxc method
Hi! While porting various packages (including Kaffe) using our cross-compiler tool-chain I discover the "depcomp" automake utility; our compiler being able to generate dependencies I would like to submit the following patch to depcomp to add a new "sxc" method (sxc is the name of our C/C++ compiler). This patch is quite simple as the preprocessor is able to generate directly the correct dependency file with dummy dependencies for all included files to avoid the "deleted header file" syndrom. The Changelog: 2000-09-05 Bernard Dautrevaux [EMAIL PROTECTED] * depcomp: Add an "sxc" method for dependencies generation The path: *** depcomp.old 2000/09/04 17:48:20 --- depcomp 2000/09/06 15:20:57 *** *** 65,68 --- 65,72 ;; + sxc) + exec "$@" -:pied="$depfile" + ;; + sgi) if "$@" -MDupdate "$tmpdepfile"; then : Bernard Dautrevaux Microprocess Ingenierie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel:+33 (0) 1 47 68 80 80 Fax:+33 (0) 1 47 88 97 85 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
