Re: utility programs used during build
Ralf Corsepius wrote:
> On Fri, 2004-01-16 at 21:00, Tom Tromey wrote:
>> > "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>>
>> But that isn't what Warren is talking about. He's talking about a
>> situation where you want to build your package for a different host,
>> but first build some helper programs on the build machine to create
>> other parts of your program.
> That's exactly the situation each sub-package underneath the (gcc,
> binutils, newlib, gdb) "ueberbaum" is facing.
>
> Each of them requires to "build some helper programs on the build
> machine, to create other parts of your program"
>
> For instance, when building a cross-gcc one-tree style,
> * the cross-binutils (target-ar, target-ld etc.) are such helper
> programs (They run on the build host).
> * from the perspective/view of the lib*-packages in gcc's source-tree,
> xgcc is such a tool.
>
>> but not really cleaner. "Clean" depends on the needs of the package
>> at hand, sometimes you'd really rather just lump all the sources
>> together.
> Well, I have been facing this issue myself. At first, it seems to be
> annoying ("What do I really need to ... it's only one file, implementing
> a little helper tool"), I had to learn it to pay off in longer terms.
>> I
>> think at least one part of this must be handled automatically,
> s/must/should/, otherwise agreed
>> and
>> that is the selection of EXEEXT, which can differ between build and
>> host.
> ACK, but I am inclined regard even as an almost marginal special case.
This corner case seems important to me.
> For simple cases, falling back to manually written make-rules using a
> handful of custom *_FOR_BUILD variables probably is the easiest way.
I don't think this is best. Consider that not everyone is using a compiler
with the same name. How do you set the $CC_FOR_BUILD without configure
macros doing it?
> Even simplier to is avoid compilation at all and implement such tools in
> a scripting language (This is what the fix*-tools/scripts in gcc do/did)
This is great until you are porting something to automake that has a
compiled build utility.
>> And really my preference would be to have it all done
>> automatically, since that is easier for the user and less
>> error-prone... still, it looks like the same internal mechanisms are
>> necessary to support build compilers and per-target compilers.
>>
>> Anyway, it looks like there's a big job ahead for Warren :-).
> :-) Don't get me wrong, though it might sound as if, I am definitely not
> wanting to discourage him nor anybody else.
> It's just that I am fighting with autoconf/automake/libtools and their
> application to cross-building for years and believe to be able to
> estimate the problems/issues ahead :-)
At the very least, could we teach automake that it is doing host
compilations. I just want to rename the host specific vars in the struct
list to host_compile, host_compiler, host_ld, host_lder, host_link, and
host_linker. This would make it more explicit that they are for host
building. I have a patch that does that for the latest CVS.
wt
--
Warren Turkal
President, GOLUM, Inc.
http://www.golum.org
Re: utility programs used during build
On Fri, 2004-01-16 at 21:00, Tom Tromey wrote:
> > "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> >> > If you want a clean way, you'd have to split buildtools and
> >> > host-packages into separate (sub) packages and write a costomized
> >> > toplevel configure-script to parse and set the configure options for
> >> > build- and host- compile packages.
>
> Ralf> This is the current nominal working principle, as it is applied by
> Ralf> packages which actually support cross-compilation (gcc, newlib,
> Ralf> binutils, gdb etc.).
>
> Hmm, I think we're mixing scenarios.
I don't think so.
> In gcc, for instance, ordinarily target libraries are put in their
> own directories with their own configuration. And there is also a
> surrounding layer of hackery to deal with multilibs.
Yes, you are referring to $target_subdir
> But that isn't what Warren is talking about. He's talking about a
> situation where you want to build your package for a different host,
> but first build some helper programs on the build machine to create
> other parts of your program.
That's exactly the situation each sub-package underneath the (gcc,
binutils, newlib, gdb) "ueberbaum" is facing.
Each of them requires to "build some helper programs on the build
machine, to create other parts of your program"
For instance, when building a cross-gcc one-tree style,
* the cross-binutils (target-ar, target-ld etc.) are such helper
programs (They run on the build host).
* from the perspective/view of the lib*-packages in gcc's source-tree,
xgcc is such a tool.
> E.g., in gcc there are the gen* family of programs, like genattrtab.
> These are just incorporated in the gcc source directory along with
> files that will be compiled for the host machine, not the build
> machine.
Yes, these are set of tools inside of the source-tree, not applying the
approach I am talking about.
> My opinion on this is that total separation is easier to implement,
Agreed, I am convinced, that not applying the "split-package" approach
will be costly in longer terms.
[Have a look at gnatlib in gcc. The Ada-folks prefer to not split out
their sources and prefer to lump together gnatlib with the rest of gnat.
Consequence: in gcc-3.3.* gnatlib can't be cross-built properly (If it
does on a particular build system, it is just a random accident, because
build system and host system are similar enough for not causing
conflicts.)]
> but not really cleaner. "Clean" depends on the needs of the package
> at hand, sometimes you'd really rather just lump all the sources
> together.
Well, I have been facing this issue myself. At first, it seems to be
annoying ("What do I really need to ... it's only one file, implementing
a little helper tool"), I had to learn it to pay off in longer terms.
> Alexandre's simple solution of overriding _CC and the like is nice.
That's not what I am referring to. I am referring to gcc's toplevel
configure script (The old "cygnus configure") and it's internal working
principle:
mkdir $target_subdir/$package
cd $target_subdir/$package;
CC=$CC_FOR_TARGET ... /$package/configure
This approach fits cleanly into the autoconf's working principles,
doesn't conflict with automake/libtool.
All that lacks to make this handy basically is
"BUILD|HOST|TARGET_CONFIG_SUBDIR" support in autoconf and "make dist"
support in automake.
> I
> think at least one part of this must be handled automatically,
s/must/should/, otherwise agreed
> and
> that is the selection of EXEEXT, which can differ between build and
> host.
ACK, but I am inclined regard even as an almost marginal special case.
IMO, the real problems are lurking in AC_TRY_COMPILE/LINK and AC_DEFINE
and everything based on them.
AC_TRY_COMPILE/LINK with the build or host compiler? Where to store
AC_DEFINEs, build or host CONFIG-header? And how to pass on INCLUDES,
LIBS, DEFS, CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS etc.?
For simple cases, falling back to manually written make-rules using a
handful of custom *_FOR_BUILD variables probably is the easiest way.
Even simplier to is avoid compilation at all and implement such tools in
a scripting language (This is what the fix*-tools/scripts in gcc do/did)
> And really my preference would be to have it all done
> automatically, since that is easier for the user and less
> error-prone... still, it looks like the same internal mechanisms are
> necessary to support build compilers and per-target compilers.
>
> Anyway, it looks like there's a big job ahead for Warren :-).
:-) Don't get me wrong, though it might sound as if, I am definitely not
wanting to discourage him nor anybody else.
It's just that I am fighting with autoconf/automake/libtools and their
application to cross-building for years and believe to be able to
estimate the problems/issues ahead :-)
Ralf
Re: utility programs used during build
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: >> > If you want a clean way, you'd have to split buildtools and >> > host-packages into separate (sub) packages and write a costomized >> > toplevel configure-script to parse and set the configure options for >> > build- and host- compile packages. Ralf> This is the current nominal working principle, as it is applied by Ralf> packages which actually support cross-compilation (gcc, newlib, Ralf> binutils, gdb etc.). Hmm, I think we're mixing scenarios. In gcc, for instance, ordinarily target libraries are put in their own directories with their own configuration. And there is also a surrounding layer of hackery to deal with multilibs. But that isn't what Warren is talking about. He's talking about a situation where you want to build your package for a different host, but first build some helper programs on the build machine to create other parts of your program. E.g., in gcc there are the gen* family of programs, like genattrtab. These are just incorporated in the gcc source directory along with files that will be compiled for the host machine, not the build machine. My opinion on this is that total separation is easier to implement, but not really cleaner. "Clean" depends on the needs of the package at hand, sometimes you'd really rather just lump all the sources together. Alexandre's simple solution of overriding _CC and the like is nice. I think at least one part of this must be handled automatically, and that is the selection of EXEEXT, which can differ between build and host. And really my preference would be to have it all done automatically, since that is easier for the user and less error-prone... still, it looks like the same internal mechanisms are necessary to support build compilers and per-target compilers. Anyway, it looks like there's a big job ahead for Warren :-). Tom
Re: utility programs used during build
On Thu, 2004-01-15 at 22:02, Warren Turkal wrote:
> Ralf Corsepius wrote:
>
> > On Thu, 2004-01-15 at 12:41, Warren Turkal wrote:
> >> This assumes that something sets those variables still (autoconf).
> >
> > Just add something similar to this
> > CC_FOR_BUILD=${CC_FOR_BUILD-${CC})
> > or
> > AS_IF([$build != $host],
> > [CC_FOR_BUILD=${CC_FOR_BUILD-cc],
> > [CC_FOR_BUILD=$CC])
> > to your configure.ac.
>
> Then you are still manually setting up this stuff.
Yes, these are hacks or to put it a bit more politely "shortcuts for
simple cases".
> > If you additionally split build-compiled tools into a separate directory
> > + Makefile.am which contains CC = @CC_FOR_BUILD@ you can use
> > automake-generated rules there.
> >
> > If you want a clean way, you'd have to split buildtools and
> > host-packages into separate (sub) packages and write a costomized
> > toplevel configure-script to parse and set the configure options for
> > build- and host- compile packages.
>
> This is just a hack.
Definitely no.
> I have seen this solution proposed before.
This is the current nominal working principle, as it is applied by
packages which actually support cross-compilation (gcc, newlib,
binutils, gdb etc.).
> It is not
> conceptually another package. Why treat it that way? I would like to have
> one configure script per package.
Why? A package may consist of multiple subpackages, can contain several
configure-scripts etc.
Also, splitting a package into build- and host- compiled packages
prepares a "large package" for multiple host-building and
Canadian-Crosses (This is the case where you actually need --target).
I guess, you've already read http://www.airs.com/ian/configure
> > automake isn't the actual problem. The actual problem is autoconf
> > support for build-compilation, because supporting build- and host-
> > compilation/checks would require to duplicate almost all autoconf
> > checks/variables etc.
>
> Automake is part of the problem.
Yes, but ... I expect these to be negligible in comparison to those
you'll probably encounter with autoconf (Think about AC_CONFIG_HEADERS).
Ralf
Re: utility programs used during build
>>> "Warren" == Warren Turkal <[EMAIL PROTECTED]> writes: Warren> Alexandre Duret-Lutz wrote: [...] >> noinst_PROGRAMS = tool1 tool2 >> tool1_SOURCES = tool1a.c tool1b.cc >> tool1_CC = $(CC_FOR_BUILD) >> tool1_CXX = $(CXX_FOR_BUILD) >> tool1_LD = $(CXXLD_FOR_BUILD) >> tool2_SOURCES = tool2.c >> >> Just a thought. Warren> This assumes that something sets those variables still Warren> (autoconf). As far as BUILD-compilation is concerned, yes. I don't think it can be avoided. Warren> Does it not make sense to have a build_PROGRAMS target Warren> supportted internally that just works for compiling Warren> these build targetted binaries? I am picturing the Warren> following. Warren> build_PROGRAMS = genkeysyms Warren> The build programs implies noinst, and the compile gets Warren> the proper options without manually overriding each var Warren> manually. It's not incompatible: it suffices to see build_ as an abbreviation for all the above. I was just trying to find a syntax that would enable things beyond BUILD-compilation. A few people have asked for ways to override the linker in the past (or maybe it was the compiler, but I seem to recall some deception with maude_LINK). -- Alexandre Duret-Lutz
Re: utility programs used during build
Ralf Corsepius wrote:
> On Thu, 2004-01-15 at 12:41, Warren Turkal wrote:
>> This assumes that something sets those variables still (autoconf).
>
> Just add something similar to this
> CC_FOR_BUILD=${CC_FOR_BUILD-${CC})
> or
> AS_IF([$build != $host],
> [CC_FOR_BUILD=${CC_FOR_BUILD-cc],
> [CC_FOR_BUILD=$CC])
> to your configure.ac.
Then you are still manually setting up this stuff.
> If you additionally split build-compiled tools into a separate directory
> + Makefile.am which contains CC = @CC_FOR_BUILD@ you can use
> automake-generated rules there.
>
> If you want a clean way, you'd have to split buildtools and
> host-packages into separate (sub) packages and write a costomized
> toplevel configure-script to parse and set the configure options for
> build- and host- compile packages.
This is just a hack. I have seen this solution proposed before. It is not
conceptually another package. Why treat it that way? I would like to have
one configure script per package.
> automake isn't the actual problem. The actual problem is autoconf
> support for build-compilation, because supporting build- and host-
> compilation/checks would require to duplicate almost all autoconf
> checks/variables etc.
Automake is part of the problem.
wt
--
Warren Turkal
President, GOLUM, Inc.
http://www.golum.org
Re: utility programs used during build
On Thu, 2004-01-15 at 12:41, Warren Turkal wrote:
> Alexandre Duret-Lutz wrote:
>
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > Tom> Well, really it might be nice to clean up target library
> > Tom> support, but I wouldn't recommend it unless you have a
> > Tom> real need; it is pretty messy.
> >
> > A simple way to support BUILD- and TARGET- compilations (and
> > more) could be to support per-target (I'm speaking of Makefile
> > targets here) compiler flags.
> >
> > It can be a bit verbose, especially if the BUILD-tool mixes
> > several languages. Here is an example where tool1 would be
> > built for BUILD, and tool2 for HOST.
> >
> > noinst_PROGRAMS = tool1 tool2
> > tool1_SOURCES = tool1a.c tool1b.cc
> > tool1_CC = $(CC_FOR_BUILD)
> > tool1_CXX = $(CXX_FOR_BUILD)
> > tool1_LD = $(CXXLD_FOR_BUILD)
> > tool2_SOURCES = tool2.c
> >
> > Just a thought.
>
> This assumes that something sets those variables still (autoconf).
Just add something similar to this
CC_FOR_BUILD=${CC_FOR_BUILD-${CC})
or
AS_IF([$build != $host],
[CC_FOR_BUILD=${CC_FOR_BUILD-cc],
[CC_FOR_BUILD=$CC])
to your configure.ac.
If you additionally split build-compiled tools into a separate directory
+ Makefile.am which contains CC = @CC_FOR_BUILD@ you can use
automake-generated rules there.
If you want a clean way, you'd have to split buildtools and
host-packages into separate (sub) packages and write a costomized
toplevel configure-script to parse and set the configure options for
build- and host- compile packages.
> Does it
> not make sense to have a build_PROGRAMS target supportted internally that
> just works for compiling these build targetted binaries?
automake isn't the actual problem. The actual problem is autoconf
support for build-compilation, because supporting build- and host-
compilation/checks would require to duplicate almost all autoconf
checks/variables etc.
Ralf
Re: utility programs used during build
Alexandre Duret-Lutz wrote: "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: > > [...] > > Tom> Well, really it might be nice to clean up target library > Tom> support, but I wouldn't recommend it unless you have a > Tom> real need; it is pretty messy. > > A simple way to support BUILD- and TARGET- compilations (and > more) could be to support per-target (I'm speaking of Makefile > targets here) compiler flags. > > It can be a bit verbose, especially if the BUILD-tool mixes > several languages. Here is an example where tool1 would be > built for BUILD, and tool2 for HOST. > > noinst_PROGRAMS = tool1 tool2 > tool1_SOURCES = tool1a.c tool1b.cc > tool1_CC = $(CC_FOR_BUILD) > tool1_CXX = $(CXX_FOR_BUILD) > tool1_LD = $(CXXLD_FOR_BUILD) > tool2_SOURCES = tool2.c > > Just a thought. This assumes that something sets those variables still (autoconf). Does it not make sense to have a build_PROGRAMS target supportted internally that just works for compiling these build targetted binaries? I am picturing the following. build_PROGRAMS = genkeysyms The build programs implies noinst, and the compile gets the proper options without manually overriding each var manually. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org
Re: utility programs used during build
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: [...] Tom> Well, really it might be nice to clean up target library Tom> support, but I wouldn't recommend it unless you have a Tom> real need; it is pretty messy. A simple way to support BUILD- and TARGET- compilations (and more) could be to support per-target (I'm speaking of Makefile targets here) compiler flags. It can be a bit verbose, especially if the BUILD-tool mixes several languages. Here is an example where tool1 would be built for BUILD, and tool2 for HOST. noinst_PROGRAMS = tool1 tool2 tool1_SOURCES = tool1a.c tool1b.cc tool1_CC = $(CC_FOR_BUILD) tool1_CXX = $(CXX_FOR_BUILD) tool1_LD = $(CXXLD_FOR_BUILD) tool2_SOURCES = tool2.c Just a thought. -- Alexandre Duret-Lutz
Re: utility programs used during build
Gary V.Vaughan wrote: > It depends on the compiler you use. If you have configured with a > crosscompiler, it will do that yes. Maybe you can override it? You > would have to copy the compile and link rules from the generated > Makefile into your Makefile.am, and then change the compiler to > $(CC_BUILD) or something... > > I didn't see your other message until after I answered this one. You > are right that it would be nicer if Automake had built in support for > such things. This is where I am intending to go. BTW, what do I need to do to get copywrite assignment paperwork done so that my hopeful changes can be incorporated without issue. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org
Re: utility programs used during build
On Tuesday, January 13, 2004, at 06:05 pm, Warren Turkal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 13 January 2004 05:54 am, Gary V. Vaughan wrote: Warren Turkal wrote: | Is there any analysis on what it would take to create utility programs | that are only used during build in a crosscompiled environment in | automake? | | I and working on the libX11 for Freedesktop.org and it builds a file and | uses it during installation, but does not install it. I am under the | impression that automake does not support this right now. What would be | needed to add support for this feature. Does this work? nodist_PROGRAMS = installtool install: installtool I don't undersand what your example does. Isn't nodist implied on PROGRAMS? Yes it is, I meant noinst_, but my fingers typed nodist_ :-/ The following example is closest I can come up with. It will not work if you are cross compiling. noinst_PROGRAMS = installtool That's what I meant. installtool_SOURCES = installtool.c This is implied. If no sources are given, $PROGRAMNAME.c is used by default. It will attempt build a host targetted binary. That binary will not run on the build system. This is why I think automake needs to be extended. It depends on the compiler you use. If you have configured with a crosscompiler, it will do that yes. Maybe you can override it? You would have to copy the compile and link rules from the generated Makefile into your Makefile.am, and then change the compiler to $(CC_BUILD) or something... I didn't see your other message until after I answered this one. You are right that it would be nicer if Automake had built in support for such things. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: utility programs used during build
> "Warren" == Warren Turkal <[EMAIL PROTECTED]> writes: Warren> Is there any analysis on what it would take to create utility Warren> programs that are only used during build in a crosscompiled Warren> environment in automake? Warren> I and working on the libX11 for Freedesktop.org and it builds Warren> a file and uses it during installation, but does not install Warren> it. I am under the impression that automake does not support Warren> this right now. What would be needed to add support for this Warren> feature. I think your plan as posted on the patch list is a good start. I always liked the gcc-style names like `CC_FOR_BUILD', `CFLAGS_FOR_BUILD'; they always seemed the easiest to understand. (Other folks have suggested BUILD_CC, BUILD_CFLAGS, etc. Which, really, aren't that much harder.) Having a `build_' prefix for primaries makes sense to me. For autoconf it would be nice if you could tell it "now I want to do checks on the host compiler" and have it change the definition of CC (and other flags), have a new build-specific config.h, etc. The required changes might be extensive. I agree with Alexandre that we don't have to support target, just host and build. Well, really it might be nice to clean up target library support, but I wouldn't recommend it unless you have a real need; it is pretty messy. Tom
Re: utility programs used during build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Warren Turkal wrote: | Is there any analysis on what it would take to create utility programs that | are only used during build in a crosscompiled environment in automake? | | I and working on the libX11 for Freedesktop.org and it builds a file and | uses it during installation, but does not install it. I am under the | impression that automake does not support this right now. What would be | needed to add support for this feature. Does this work? nodist_PROGRAMS = installtool install: installtool - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAA9x2FRMICSmD1gYRAtCyAJ9iO0eW5/THZIhH7qPAsxbOuh9IeQCgiB6p EYf81/l4CKfrlrM+/tgJL0Y= =TxXU -END PGP SIGNATURE-
utility programs used during build
Is there any analysis on what it would take to create utility programs that are only used during build in a crosscompiled environment in automake? I and working on the libX11 for Freedesktop.org and it builds a file and uses it during installation, but does not install it. I am under the impression that automake does not support this right now. What would be needed to add support for this feature. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org
