[LLVMdev] UPDATE: Automake Difficulties (Long)

[Vladimir Prus]

On Thursday 21 October 2004 21:51, Alkis Evlogimenos wrote:

> > Boost.Build supports this very good. In particular, on my project on work
> > I can run:
> >
> >    bjam toolset=gcc
> >    bjam toolset=nm
> >    bjam toolset=nmm
> >
> > and the first will do a regular build, the third will compile for some
> > embedded processor, and the third will pass the sources via some
> > annotation tool and produce an annotated x86 binary.
> >
> > Besides, "toolset=gcc" can become "toolset=msvc" on windows, and it will
> > have high chances of working.
>
> I don't think Reid was referring to the use of different compilers on
> (possibly) different platforms. If you look at runtime/GC/SemiSpace: those
> files are not compiled using the compiler used to compile the rest of the
> project (llc, lli and so on). They use the llvm-gcc-frontend to compile and
> link those libraries into llvm bytecode. The resulting files end up in
> runtime/GC/SemiSpace/BytecodeObj

Yes, that should work. That's exactly different compiler: the sources must be 
compiled with llvm-gcc, not with regular gcc. 

> > > 2. The entire llvm-test project would have to either be completely
> > > rethought or stay the way it is, it just can't be easily automake'd
> > > because it doesn't follow the automake pattern.
> > >
> > > 3. The llvm/test directory would require significant rework to get it
> > > to automake correctly (via dejagnu).
> >
> > No comments on the two points above yet.
>
> Any ideas if the boost testing framework can apply to these two points?

Not yet. Boost frameworks allows to run executable, check if it failed or not, 
and gather that in a nice table. It's hard to say what hidden problems are 
there.

> > > 6. Creating a distribution tarball would require additional Makefile.am
> > > files to be inserted in all the directories under llvm/include, the
> > > traversal of which would cause additional overhead for every non-dist
> > > target. That's 17 gratuitous "make" processes per build.  There doesn't
> > > seem to be a way around this.
> >
> > Why distribution tarball has anything to do with build system?
>
> This is done in automake. Because the distribution consists of files
> processed by automake, the "distcheck" target makes sure that those files
> are in the distribution and the distribution tarball can build properly
> without needing automake/autoconf.

Ah... should not be necessary with Boost.Build.

> > Basically, I can try to finish my attempt to add Boost.Build files to
> > LLVM. But I wonder if that makes sense? Is it already decided to just
> > improve the current system?
>
> I don't think it is set on stone to keep the current system. We are always
> open to new ideas and if they improve things we will most likely adopt
> them. I would say you should proceed on finishing what you have and we can
> test it and see how it compares with the current system.

Thanks. I'll proceed then.

> Just for clarification: the only requirement for Boost.Build is bjam
> itself, right?

Right, plus the Boost.Build implementation files. But since they are in an 
interpreted language, they pose much less problems. They even can be added to 
distribution.

> > 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 :-)

Ok, just was just making sure ;-)

- Volodya