similar to: [LLVMdev] UPDATE: AUtomake Difficulties (Long)

I'm re-thinking my penchant for automake. automake is great for many standard applications that just need to get portable makefiles up and running quickly. However, it turns out that LLVM is "different enough" from a standard application that automake might not be the best choice. Here's some of the problems I've run into: 1. There's no way to tell automake to build

On Thursday 21 October 2004 01:54, Vladimir Prus wrote: > On Wednesday 20 October 2004 12:01, Reid Spencer wrote: > > I'm re-thinking my penchant for automake. automake is great for many > > standard applications that just need to get portable makefiles up and > > running quickly. However, it turns out that LLVM is "different enough" > > from a standard

On Wednesday 20 October 2004 12:01, Reid Spencer wrote: > I'm re-thinking my penchant for automake. automake is great for many > standard applications that just need to get portable makefiles up and > running quickly. However, it turns out that LLVM is "different enough" > from a standard application that automake might not be the best choice. I might just here to

One more update. The Makefile.am for analyze was wrong. It wasn't linking in the some of the passes. The new size is 56951088 which is in line with the other executables. Also, I have now completed a run of projects/llvm-test/MultiSource with the tools generated by automake. The only errors were for: TEST (llc) 'sgefa' FAILED! TEST (jit) 'sgefa' FAILED! TEST (jit)

After puzzling about the size of the executables and the build times, I discovered (thanks Chris!) that I had compiled everything without debug symbols in the automake version. So, here's some revision from the first version of this email. The build times didn't change much (I guess I/O is cheap on my machine). The new "Build With Automake" times are 20m28.672s (elapsed),

Folks, I have completed the addition of automake makefiles to LLVM. All libraries, tools, and runtime libs build now with automake. Note that there are still many missing things in the automake support. Right now it just builds the basic software. However, before I invest more time in it, I thought some comparison would help us make some decisions about whether or not to proceed with automake

> > > 6. Have you given any thought to using automake to generate your > > > Makefiles? I use automake extensively and would prefer to > > > continue to use it with LLVM. It is simple and works well on > > > many platforms. If you'd like to go this route, I'd be willing > > > to do the conversion for you.

Dear NUT developers, I have converted NUT's build system to Automake/Libtool. Right now, the new build system is contained in the "automake" branch, at: ssh://svn.debian.org/svn/nut/branches/automake I plan to merge this into the main branch after a period of testing, if there are no objections. Here are some highlights: * automatic dependency tracking: no more need to do this

On Thu, 21 Oct 2004, John Criswell wrote: > Alkis Evlogimenos wrote: > [snip] > > > >>Is anything with "Boost" in name will be rejected right away? > > > > > > Absolutely not! We were using one of the boost libraries before and we > > replaced it because it was easy to do and it removed one external dependency > > for us, not because it

Alkis Evlogimenos wrote: [snip] > >>Is anything with "Boost" in name will be rejected right away? > > > Absolutely not! We were using one of the boost libraries before and we > replaced it because it was easy to do and it removed one external dependency > for us, not because it had the "Boost" in name :-) > Another consideration is that we try

On Sun, 2004-10-10, Misha Brukman asked "Why can't we use wildcards instead of listing all the sources" and then wrote in response to my reply: > On Sun, Oct 10, 2004 at 04:40:48PM -0700, Reid Spencer wrote: > > http://www.gnu.org/software/automake/manual/html_mono/automake.html#wildcards > > > > is your answer. > > I think their "answer" is

I make changes in open source tree to implement autoconf/automake. What's new ? - new acinclude.m4 ( based on old aclocal.m4 + new macros OSSH_EXPAND_PATHS and OSSH_SHOW_OPTIONS - new configure option --with-askpass=PATH - updated acconfig.h ( based on old acconfig.h with removed USE_EXTERNAL_ASKPASS and new ASKPASS_PATH + new config.h.top and config.h.bot ) !!! in this file has two lines

John, The point I was trying to make (and obviously didn't) was that because automake can make the mechanics of building/testing/packaging a release so much easier (one command), it is possible for this to be automated regularly (e.g. nightly test). Consequently, the problems only seen when building a distribution would be available much sooner than the week before the release. Distribution

Reid Spencer wrote: > On Sun, 2004-10-10, Misha Brukman asked "Why can't we use wildcards > instead of listing all the sources" and then wrote in response to my > reply: > >>On Sun, Oct 10, 2004 at 04:40:48PM -0700, Reid Spencer wrote: >> >>>http://www.gnu.org/software/automake/manual/html_mono/automake.html#wildcards >>> >>>is your

Hi, I've taken a small bit of time to initiate this work. There is now: - an m4 macro to detect the system (linux only ATM, but simple to complete) - a set of "make package" targets throughout the tree (limited to debian ATM) The remaining tasks on this specific point are: - m4 macro completion to handle all the supported platforms (at least the ones that have files in the

On 10/15/06, Peter Selinger <selinger@mathstat.dal.ca> wrote: > I have converted NUT's build system to Automake/Libtool. Right now, > the new build system is contained in the "automake" branch, at: Wow... this is really nice. Thanks for taking the time to do the conversion. > drivers/Doxyfile - this seems to belong to Charles. Perhaps >

Hi Reid, just a quick note while you're doing this, a while ago I ran into a problem that the standard makefiles weren't building libraries (like, say, a new pass) correctly on OS X - they were being built as shared libraries and not bundles, so they couldn't be loaded with dlopen. The discussion is in the archives if you want more details... I fixed it locally by doing the following

Since we also ``sometimes'' have problems with incorrect configurations... ;-) Read this on the octave mailing list : (I'm not using octave; I'm trying to hear what they are talking about) ------- Start of forwarded message ------- Date: Mon, 17 May 1999 10:30:51 +0200 From: Thomas Walter <walter@pctc.chemie.uni-erlangen.de> To: jwe@bevo.che.wisc.edu CC:

If you rebuild the Makefiles using automake >= 1.13 then you'll likely hit this error: Makefile:1904: *** unterminated variable reference. Stop. This is caused by automake miscompiling GNU make macros that appear in the 'TESTS' variable decl in 'ocaml/Makefile.am'. I posted a bug about this upstream. It hasn't appeared yet, but it should turn up here in the near

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Boll (6): radeon: Wire up radeon-symbol-check to make check automake: Don't include Android Makefiles in the release tarball virtgpu: Update kernel header automake: Include virtgpu_drm.h in the release tarball man: Fix typo radeon: Fix typo in stderr message Emil Velikov (2):