Re: compilers that self compile
On Fri, Oct 22, 2004 at 10:05:48AM -0300, Antonio S. de A. Terceiro wrote: Joel Baker escreveu isso aí: [cut] Will this approach make manual porting unnecessary? Sadly, no, at least if I understand you correctly. Because, four months down the road when you've uploaded another copy to the archive, that first copy with the pre-translated source that you built will be long gone and unavailable for use - and requiring the use of upstreams binary precompile is impractical in many situations (such as It's a new port and upstream doesn't have one out yet, or may never put one out). If it is possible to install the tool on another Debian box and *generate* the necessary files, before trying to do the build, and use those, that would generally be workable; most porters have access to, if nothing else, the Debian machines used for troubleshooting various things, and could compile it there. However, if it's that complex, I strongly advise writing your rules file to make it as easy as possible, and putting at note in near the top such as # Porters - please see the BOOTSTRAPPING file for instructions on building this package on a new port. And, of course, document the step by step way of doing this in that file (which, if you're doing it for the first time yourself to get the package into the archive, should be easy enough - just Let me be sure I've understood. ac++ does source-to-source-translation, and the generated sources are platform-independent. For building it for the first time, I'll have to install on my box (i386) a binary distributed by upstream for i386 (the only architecture for which they provide binaries), and build it normally. Then, for architectures other than i386, porters will do the same what I did (assuming that I'll document it in the debian/rules file), using some i386 box they have access to generate the C++ source, copy these sources to a target-architecture box, and build it themselves. Is that it? What I thought is that if the translated sources (which are platform independent) went in the diff, there will be no necessary by hand actions for building in any architecture. But as Joeren wrote, one it is not recommended to do that. Am I correct? Sorry this took a while to respond to; life sort of got in the way. If the generated sources are platform independant, and you can use the Debian package for i386 to generate enough to bootstrap something on another port, then yes, that's quite sufficient (but might still be good to note somewhere, so folks trying to port it realize that it's that simple). Putting the post-translated sources into the package is not, as a rule, a good idea, for the reasons mentioned before, but so long as the tools necessary to do the bootstrapping are readily available and there's a note about how to use them to do it, porters won't generally have any problems (the usual routine is to build the package manually, by hand, in this case using sources generated with the i386 binary, then install it into the porting area and do a 'normal' build using the bootstrapped package to ensure that all of the other Build-Depends and such are OK, and use the second stage package as the thing to upload). The fact that the translated sources are portable makes it vastly simpler, since it reduces the requirement for a new port from a binary copy must exist for this architecture to a binary copy must exist for SOME architecture you have access to, and nearly every porter I know of has at least passing access to an i386 box where they could arrange for it to be installed long enough to bootstrap the port. -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: compilers that self compile
On Fri, Oct 22, 2004 at 10:05:48AM -0300, Antonio S. de A. Terceiro wrote: Joel Baker escreveu isso aí: [cut] Will this approach make manual porting unnecessary? Sadly, no, at least if I understand you correctly. Because, four months down the road when you've uploaded another copy to the archive, that first copy with the pre-translated source that you built will be long gone and unavailable for use - and requiring the use of upstreams binary precompile is impractical in many situations (such as It's a new port and upstream doesn't have one out yet, or may never put one out). If it is possible to install the tool on another Debian box and *generate* the necessary files, before trying to do the build, and use those, that would generally be workable; most porters have access to, if nothing else, the Debian machines used for troubleshooting various things, and could compile it there. However, if it's that complex, I strongly advise writing your rules file to make it as easy as possible, and putting at note in near the top such as # Porters - please see the BOOTSTRAPPING file for instructions on building this package on a new port. And, of course, document the step by step way of doing this in that file (which, if you're doing it for the first time yourself to get the package into the archive, should be easy enough - just Let me be sure I've understood. ac++ does source-to-source-translation, and the generated sources are platform-independent. For building it for the first time, I'll have to install on my box (i386) a binary distributed by upstream for i386 (the only architecture for which they provide binaries), and build it normally. Then, for architectures other than i386, porters will do the same what I did (assuming that I'll document it in the debian/rules file), using some i386 box they have access to generate the C++ source, copy these sources to a target-architecture box, and build it themselves. Is that it? What I thought is that if the translated sources (which are platform independent) went in the diff, there will be no necessary by hand actions for building in any architecture. But as Joeren wrote, one it is not recommended to do that. Am I correct? Sorry this took a while to respond to; life sort of got in the way. If the generated sources are platform independant, and you can use the Debian package for i386 to generate enough to bootstrap something on another port, then yes, that's quite sufficient (but might still be good to note somewhere, so folks trying to port it realize that it's that simple). Putting the post-translated sources into the package is not, as a rule, a good idea, for the reasons mentioned before, but so long as the tools necessary to do the bootstrapping are readily available and there's a note about how to use them to do it, porters won't generally have any problems (the usual routine is to build the package manually, by hand, in this case using sources generated with the i386 binary, then install it into the porting area and do a 'normal' build using the bootstrapped package to ensure that all of the other Build-Depends and such are OK, and use the second stage package as the thing to upload). The fact that the translated sources are portable makes it vastly simpler, since it reduces the requirement for a new port from a binary copy must exist for this architecture to a binary copy must exist for SOME architecture you have access to, and nearly every porter I know of has at least passing access to an i386 box where they could arrange for it to be installed long enough to bootstrap the port. -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: compilers that self compile
Joel Baker escreveu isso aí: [cut] Will this approach make manual porting unnecessary? Sadly, no, at least if I understand you correctly. Because, four months down the road when you've uploaded another copy to the archive, that first copy with the pre-translated source that you built will be long gone and unavailable for use - and requiring the use of upstreams binary precompile is impractical in many situations (such as It's a new port and upstream doesn't have one out yet, or may never put one out). If it is possible to install the tool on another Debian box and *generate* the necessary files, before trying to do the build, and use those, that would generally be workable; most porters have access to, if nothing else, the Debian machines used for troubleshooting various things, and could compile it there. However, if it's that complex, I strongly advise writing your rules file to make it as easy as possible, and putting at note in near the top such as # Porters - please see the BOOTSTRAPPING file for instructions on building this package on a new port. And, of course, document the step by step way of doing this in that file (which, if you're doing it for the first time yourself to get the package into the archive, should be easy enough - just Let me be sure I've understood. ac++ does source-to-source-translation, and the generated sources are platform-independent. For building it for the first time, I'll have to install on my box (i386) a binary distributed by upstream for i386 (the only architecture for which they provide binaries), and build it normally. Then, for architectures other than i386, porters will do the same what I did (assuming that I'll document it in the debian/rules file), using some i386 box they have access to generate the C++ source, copy these sources to a target-architecture box, and build it themselves. Is that it? What I thought is that if the translated sources (which are platform independent) went in the diff, there will be no necessary by hand actions for building in any architecture. But as Joeren wrote, one it is not recommended to do that. Am I correct? -- Antonio S. de A. Terceiro [EMAIL PROTECTED] http://www.inf.ufrgs.br/~asaterceiro Chave PGP/PGP key -- http://pgp.mit.edu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compilers that self compile
Joel Baker escreveu isso aí: [cut] Will this approach make manual porting unnecessary? Sadly, no, at least if I understand you correctly. Because, four months down the road when you've uploaded another copy to the archive, that first copy with the pre-translated source that you built will be long gone and unavailable for use - and requiring the use of upstreams binary precompile is impractical in many situations (such as It's a new port and upstream doesn't have one out yet, or may never put one out). If it is possible to install the tool on another Debian box and *generate* the necessary files, before trying to do the build, and use those, that would generally be workable; most porters have access to, if nothing else, the Debian machines used for troubleshooting various things, and could compile it there. However, if it's that complex, I strongly advise writing your rules file to make it as easy as possible, and putting at note in near the top such as # Porters - please see the BOOTSTRAPPING file for instructions on building this package on a new port. And, of course, document the step by step way of doing this in that file (which, if you're doing it for the first time yourself to get the package into the archive, should be easy enough - just Let me be sure I've understood. ac++ does source-to-source-translation, and the generated sources are platform-independent. For building it for the first time, I'll have to install on my box (i386) a binary distributed by upstream for i386 (the only architecture for which they provide binaries), and build it normally. Then, for architectures other than i386, porters will do the same what I did (assuming that I'll document it in the debian/rules file), using some i386 box they have access to generate the C++ source, copy these sources to a target-architecture box, and build it themselves. Is that it? What I thought is that if the translated sources (which are platform independent) went in the diff, there will be no necessary by hand actions for building in any architecture. But as Joeren wrote, one it is not recommended to do that. Am I correct? -- Antonio S. de A. Terceiro [EMAIL PROTECTED] http://www.inf.ufrgs.br/~asaterceiro Chave PGP/PGP key -- http://pgp.mit.edu/
Re: compilers that self compile
Re: Jeroen van Wolffelaar in [EMAIL PROTECTED] * how packages like those go in the repository for the first time? By ignoring build-depends while in some way you've made your system to actually be able to build the package. I.e., you've for example bootstrapped the compiler. Then you install it locally, and build your package again, this time the normal way, and you upload it. After it's in the archive, it's rebuildable by itself. Of course, the bootstrapping has to be done for each architecture again. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: compilers that self compile
On Thu, Oct 21, 2004 at 03:35:14PM +0200, Christoph Berg wrote: Re: Jeroen van Wolffelaar in [EMAIL PROTECTED] * how packages like those go in the repository for the first time? By ignoring build-depends while in some way you've made your system to actually be able to build the package. I.e., you've for example bootstrapped the compiler. Then you install it locally, and build your package again, this time the normal way, and you upload it. After it's in the archive, it's rebuildable by itself. Of course, the bootstrapping has to be done for each architecture again. Yes, it will. Which will make those of us porting put your package at the very end of the queue of things to be ported, unless something else is forcing it higher (in which case, we'll just be very annoyed at the package, unless bootstrapping is trivial). I would strongly suggest considering what makes it self-depend (there are legitimate reasons, yes), and how one could deal with that in the case of bootstrapping. For GCC, it's fairly simple; one has to bootstrap it with another C compiler, but *any* compiler will do, more or less, including a cross-compiler or a native package from another OS that happens to target the platform required. In theory, everything in Essential and Build-Essential is actually self-dependant, because those two must (in theory) be met before one can safely build a package, even one with no Build-Depends. However, in practice, most of these can be remotely compiled, or copied from an existing source, and work well enough to allow one to compile the packages properly. And, of course, packages which Build-Depend on some part of themselves which is Arch: all aren't terribly problematic, since the old package is already available in the archive, and can be installed anywhere. The problem comes in when you have packages that are (perhaps gratuitously) self-dependant, on binary packages, and which are not readily available from simple manual compilations. If I have to spend hours building a package just to have enough to rebuild it as a Debian package, it's going *far* down the list. GCC is about the only exception I can think of offhand. (And, frankly, in some ways the port I work on - NetBSD/i386 - has it easier, because often there is a working NetBSD-native package that can be compiled and the bits copied into the Debian area long enough to bootstrap.) One solution which has been known to work reasonably is to allow a build-option (documented in the rules file, please!) that allows a crippled version of the package to be built without needing recursive dependancies. The porter builds it, installs it locally only, then rebuilds the full and proper package and uploads that (and, of course, after that it isn't an issue). -- Joel Baker [EMAIL PROTECTED],''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: compilers that self compile
Joel Baker escreveu isso aí: On Thu, Oct 21, 2004 at 03:35:14PM +0200, Christoph Berg wrote: Re: Jeroen van Wolffelaar in [EMAIL PROTECTED] * how packages like those go in the repository for the first time? By ignoring build-depends while in some way you've made your system to actually be able to build the package. I.e., you've for example bootstrapped the compiler. Then you install it locally, and build your package again, this time the normal way, and you upload it. After it's in the archive, it's rebuildable by itself. Of course, the bootstrapping has to be done for each architecture again. Yes, it will. Which will make those of us porting put your package at the very end of the queue of things to be ported, unless something else is forcing it higher (in which case, we'll just be very annoyed at the package, unless bootstrapping is trivial). In my case, it is ac++ [1] [2], an Aspect Weaver that makes source-to-source translation. This translation is needed in a part of itself (there are good reasons for that). [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277538 [2] http://www.aspectc.org My idea is to make a first release with sources already translated (which can be done with a precompiled binary for i386 distributed by upstream), which would compile fine with just g++ and libxml2-dev as build-dependencies. Then, when/if it goes into repository, it will be possible to compile a second release from untranslated sources, since ac++ itself will be already available. I've requested that upstream distribute one version already translated. .orig.tar.gz has to be officially distributed by upstream to be considered pristine, hasn't it? Will this approach make manual porting unnecessary? -- Antonio S. de A. Terceiro [EMAIL PROTECTED] http://www.inf.ufrgs.br/~asaterceiro Chave PGP/PGP key -- http://pgp.mit.edu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compilers that self compile
On Thu, Oct 21, 2004 at 02:33:35PM -0300, Antonio S. de A. Terceiro wrote: Joel Baker escreveu isso aí: On Thu, Oct 21, 2004 at 03:35:14PM +0200, Christoph Berg wrote: Re: Jeroen van Wolffelaar in [EMAIL PROTECTED] * how packages like those go in the repository for the first time? By ignoring build-depends while in some way you've made your system to actually be able to build the package. I.e., you've for example bootstrapped the compiler. Then you install it locally, and build your package again, this time the normal way, and you upload it. After it's in the archive, it's rebuildable by itself. Of course, the bootstrapping has to be done for each architecture again. Yes, it will. Which will make those of us porting put your package at the very end of the queue of things to be ported, unless something else is forcing it higher (in which case, we'll just be very annoyed at the package, unless bootstrapping is trivial). In my case, it is ac++ [1] [2], an Aspect Weaver that makes source-to-source translation. This translation is needed in a part of itself (there are good reasons for that). [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277538 [2] http://www.aspectc.org My idea is to make a first release with sources already translated (which can be done with a precompiled binary for i386 distributed by upstream), which would compile fine with just g++ and libxml2-dev as build-dependencies. Then, when/if it goes into repository, it will be possible to compile a second release from untranslated sources, since ac++ itself will be already available. I've requested that upstream distribute one version already translated. .orig.tar.gz has to be officially distributed by upstream to be considered pristine, hasn't it? Will this approach make manual porting unnecessary? Sadly, no, at least if I understand you correctly. Because, four months down the road when you've uploaded another copy to the archive, that first copy with the pre-translated source that you built will be long gone and unavailable for use - and requiring the use of upstreams binary precompile is impractical in many situations (such as It's a new port and upstream doesn't have one out yet, or may never put one out). If it is possible to install the tool on another Debian box and *generate* the necessary files, before trying to do the build, and use those, that would generally be workable; most porters have access to, if nothing else, the Debian machines used for troubleshooting various things, and could compile it there. However, if it's that complex, I strongly advise writing your rules file to make it as easy as possible, and putting at note in near the top such as # Porters - please see the BOOTSTRAPPING file for instructions on building this package on a new port. And, of course, document the step by step way of doing this in that file (which, if you're doing it for the first time yourself to get the package into the archive, should be easy enough - just write down what you're doing, every step of the way). -- Joel Baker [EMAIL PROTECTED],''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: compilers that self compile
On Thu, Oct 21, 2004 at 02:33:35PM -0300, Antonio S. de A. Terceiro wrote: My idea is to make a first release with sources already translated (which can be done with a precompiled binary for i386 distributed by upstream), which would compile fine with just g++ and libxml2-dev as build-dependencies. Then, when/if it goes into repository, it will be possible to compile a second release from untranslated sources, since ac++ itself will be already available. I'd not suggest to do so, because you're then having a pre-translated source in as source package, something that would be non-trivial to just modify and then work with changes -- a requirement for Debian main. I've requested that upstream distribute one version already translated. .orig.tar.gz has to be officially distributed by upstream to be considered pristine, hasn't it? It isn't a requirement that the .orig.tar.gz is identical to upstream, but anyway, you can always add stuff in the diff if you want. However, in this case I wouldn't go that route. I suggest to locally on your own system do whatever you need to do to get a ac++ package (and indeed document this carefully in the rules file). If the translations are architecture independent, and available on some upstream website, that'd make it easy for porters. Then, you can build-depend on your self, and make sure you have a ac++ source package that can build itself from pristine .orig.tar.gz without any help (just requiring the ac++ being installed already). If this succeeds, you can upload this ac++ package, once it's in unstable, it can also be build in unstable, using itself. Note: I'm not a porter. Will this approach make manual porting unnecessary? Possibly, but while you include such hand-crafted translations somewhere in the source package, I doubt it's satisfying all of the DFSG guidelines. You could of course still do so, and file a RC bug on your own package while you have this hack in place, so to easy porting indeed... But that'd be quite hacky, and I'm quite unsure whether such a tactic would be appreciated. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compilers that self compile
Re: Jeroen van Wolffelaar in [EMAIL PROTECTED] * how packages like those go in the repository for the first time? By ignoring build-depends while in some way you've made your system to actually be able to build the package. I.e., you've for example bootstrapped the compiler. Then you install it locally, and build your package again, this time the normal way, and you upload it. After it's in the archive, it's rebuildable by itself. Of course, the bootstrapping has to be done for each architecture again. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: compilers that self compile
On Thu, Oct 21, 2004 at 03:35:14PM +0200, Christoph Berg wrote: Re: Jeroen van Wolffelaar in [EMAIL PROTECTED] * how packages like those go in the repository for the first time? By ignoring build-depends while in some way you've made your system to actually be able to build the package. I.e., you've for example bootstrapped the compiler. Then you install it locally, and build your package again, this time the normal way, and you upload it. After it's in the archive, it's rebuildable by itself. Of course, the bootstrapping has to be done for each architecture again. Yes, it will. Which will make those of us porting put your package at the very end of the queue of things to be ported, unless something else is forcing it higher (in which case, we'll just be very annoyed at the package, unless bootstrapping is trivial). I would strongly suggest considering what makes it self-depend (there are legitimate reasons, yes), and how one could deal with that in the case of bootstrapping. For GCC, it's fairly simple; one has to bootstrap it with another C compiler, but *any* compiler will do, more or less, including a cross-compiler or a native package from another OS that happens to target the platform required. In theory, everything in Essential and Build-Essential is actually self-dependant, because those two must (in theory) be met before one can safely build a package, even one with no Build-Depends. However, in practice, most of these can be remotely compiled, or copied from an existing source, and work well enough to allow one to compile the packages properly. And, of course, packages which Build-Depend on some part of themselves which is Arch: all aren't terribly problematic, since the old package is already available in the archive, and can be installed anywhere. The problem comes in when you have packages that are (perhaps gratuitously) self-dependant, on binary packages, and which are not readily available from simple manual compilations. If I have to spend hours building a package just to have enough to rebuild it as a Debian package, it's going *far* down the list. GCC is about the only exception I can think of offhand. (And, frankly, in some ways the port I work on - NetBSD/i386 - has it easier, because often there is a working NetBSD-native package that can be compiled and the bits copied into the Debian area long enough to bootstrap.) One solution which has been known to work reasonably is to allow a build-option (documented in the rules file, please!) that allows a crippled version of the package to be built without needing recursive dependancies. The porter builds it, installs it locally only, then rebuilds the full and proper package and uploads that (and, of course, after that it isn't an issue). -- Joel Baker [EMAIL PROTECTED],''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: compilers that self compile
On Thu, Oct 21, 2004 at 02:33:35PM -0300, Antonio S. de A. Terceiro wrote: Joel Baker escreveu isso aí: On Thu, Oct 21, 2004 at 03:35:14PM +0200, Christoph Berg wrote: Re: Jeroen van Wolffelaar in [EMAIL PROTECTED] * how packages like those go in the repository for the first time? By ignoring build-depends while in some way you've made your system to actually be able to build the package. I.e., you've for example bootstrapped the compiler. Then you install it locally, and build your package again, this time the normal way, and you upload it. After it's in the archive, it's rebuildable by itself. Of course, the bootstrapping has to be done for each architecture again. Yes, it will. Which will make those of us porting put your package at the very end of the queue of things to be ported, unless something else is forcing it higher (in which case, we'll just be very annoyed at the package, unless bootstrapping is trivial). In my case, it is ac++ [1] [2], an Aspect Weaver that makes source-to-source translation. This translation is needed in a part of itself (there are good reasons for that). [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277538 [2] http://www.aspectc.org My idea is to make a first release with sources already translated (which can be done with a precompiled binary for i386 distributed by upstream), which would compile fine with just g++ and libxml2-dev as build-dependencies. Then, when/if it goes into repository, it will be possible to compile a second release from untranslated sources, since ac++ itself will be already available. I've requested that upstream distribute one version already translated. .orig.tar.gz has to be officially distributed by upstream to be considered pristine, hasn't it? Will this approach make manual porting unnecessary? Sadly, no, at least if I understand you correctly. Because, four months down the road when you've uploaded another copy to the archive, that first copy with the pre-translated source that you built will be long gone and unavailable for use - and requiring the use of upstreams binary precompile is impractical in many situations (such as It's a new port and upstream doesn't have one out yet, or may never put one out). If it is possible to install the tool on another Debian box and *generate* the necessary files, before trying to do the build, and use those, that would generally be workable; most porters have access to, if nothing else, the Debian machines used for troubleshooting various things, and could compile it there. However, if it's that complex, I strongly advise writing your rules file to make it as easy as possible, and putting at note in near the top such as # Porters - please see the BOOTSTRAPPING file for instructions on building this package on a new port. And, of course, document the step by step way of doing this in that file (which, if you're doing it for the first time yourself to get the package into the archive, should be easy enough - just write down what you're doing, every step of the way). -- Joel Baker [EMAIL PROTECTED],''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: compilers that self compile
On Thu, Oct 21, 2004 at 02:33:35PM -0300, Antonio S. de A. Terceiro wrote: My idea is to make a first release with sources already translated (which can be done with a precompiled binary for i386 distributed by upstream), which would compile fine with just g++ and libxml2-dev as build-dependencies. Then, when/if it goes into repository, it will be possible to compile a second release from untranslated sources, since ac++ itself will be already available. I'd not suggest to do so, because you're then having a pre-translated source in as source package, something that would be non-trivial to just modify and then work with changes -- a requirement for Debian main. I've requested that upstream distribute one version already translated. .orig.tar.gz has to be officially distributed by upstream to be considered pristine, hasn't it? It isn't a requirement that the .orig.tar.gz is identical to upstream, but anyway, you can always add stuff in the diff if you want. However, in this case I wouldn't go that route. I suggest to locally on your own system do whatever you need to do to get a ac++ package (and indeed document this carefully in the rules file). If the translations are architecture independent, and available on some upstream website, that'd make it easy for porters. Then, you can build-depend on your self, and make sure you have a ac++ source package that can build itself from pristine .orig.tar.gz without any help (just requiring the ac++ being installed already). If this succeeds, you can upload this ac++ package, once it's in unstable, it can also be build in unstable, using itself. Note: I'm not a porter. Will this approach make manual porting unnecessary? Possibly, but while you include such hand-crafted translations somewhere in the source package, I doubt it's satisfying all of the DFSG guidelines. You could of course still do so, and file a RC bug on your own package while you have this hack in place, so to easy porting indeed... But that'd be quite hacky, and I'm quite unsure whether such a tactic would be appreciated. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: compilers that self compile
On Wed, Oct 20, 2004 at 01:18:39PM -0300, Antonio S. de A. Terceiro wrote: Hello all, How do people in Debian handle compilers that depend on itself to be compiled? I asked this question a while ago too. Quoting DWN[1]: | Cyclic Build Dependencies. Jeroen van Wolffelaar [11]noticed that | [12]oaklisp contains a binary file which is used for bootstrapping. | There are at least half a dozen such [13]loops in Debian already. | Edmund Grimley Evans [14]assumed that such cyclic build dependencies | are acceptable in Debian. | | 11. http://lists.debian.org/debian-legal/2004/06/msg00113.html | 12. http://packages.debian.org/oaklisp | 13. http://lists.debian.org/debian-legal/2004/06/msg00116.html | 14. http://lists.debian.org/debian-legal/2004/06/msg00114.html So, yes, that's acceptable[2]. You must ensure you can change sources as you like, and then get a new package, but you don't need to make bootstrapping possible/easy. * can a package build-depend on itself? I've saw that gcc, for example, don't (at least explicitily) build-depend on itself. It does in a way: build-essential is an assumed build-dependency, and gcc is depended on by build-essential. ghc6 does build-depend on itself. * how packages like those go in the repository for the first time? By ignoring build-depends while in some way you've made your system to actually be able to build the package. I.e., you've for example bootstrapped the compiler. Then you install it locally, and build your package again, this time the normal way, and you upload it. After it's in the archive, it's rebuildable by itself. I couldn't find references about that on either in Debian Policy Manual or in Debian Developer's Reference. If I missed something, please point me were. This is indeed something which IMHO needs to be clarified. --Jeroen [1] http://www.debian.org/News/weekly/2004/24/ [2] Technically, this very issue was not a cyclic build-depends at package level, but there was some 'binary in source package' hack involved -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compilers that self compile
Antonio S. de A. Terceiro [u] wrote on 20/10/2004 18:18: How do people in Debian handle compilers that depend on itself to be compiled? Good question. More precisely: * can a package build-depend on itself? I've saw that gcc, for example, don't (at least explicitily) build-depend on itself. gcc doesn't depend on itself to be built, but it needs _any_ C compiler available to compile an intermediate state of itself, which (basically) then compiles the final stage. That final stage than compiles itself again to check wether the output it the same as from the second compile. * how packages like those go in the repository for the first time? They probably only can go in if there is an alternate way of compiling it, like there is with gcc. I couldn't find references about that on either in Debian Policy Manual or in Debian Developer's Reference. If I missed something, please point me were. I would be interested in the solution, too, but so far I don't know a single compiler which absolutely needs itself to compile. cu, sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compilers that self compile
On Wed, Oct 20, 2004 at 01:18:39PM -0300, Antonio S. de A. Terceiro wrote: Hello all, How do people in Debian handle compilers that depend on itself to be compiled? I asked this question a while ago too. Quoting DWN[1]: | Cyclic Build Dependencies. Jeroen van Wolffelaar [11]noticed that | [12]oaklisp contains a binary file which is used for bootstrapping. | There are at least half a dozen such [13]loops in Debian already. | Edmund Grimley Evans [14]assumed that such cyclic build dependencies | are acceptable in Debian. | | 11. http://lists.debian.org/debian-legal/2004/06/msg00113.html | 12. http://packages.debian.org/oaklisp | 13. http://lists.debian.org/debian-legal/2004/06/msg00116.html | 14. http://lists.debian.org/debian-legal/2004/06/msg00114.html So, yes, that's acceptable[2]. You must ensure you can change sources as you like, and then get a new package, but you don't need to make bootstrapping possible/easy. * can a package build-depend on itself? I've saw that gcc, for example, don't (at least explicitily) build-depend on itself. It does in a way: build-essential is an assumed build-dependency, and gcc is depended on by build-essential. ghc6 does build-depend on itself. * how packages like those go in the repository for the first time? By ignoring build-depends while in some way you've made your system to actually be able to build the package. I.e., you've for example bootstrapped the compiler. Then you install it locally, and build your package again, this time the normal way, and you upload it. After it's in the archive, it's rebuildable by itself. I couldn't find references about that on either in Debian Policy Manual or in Debian Developer's Reference. If I missed something, please point me were. This is indeed something which IMHO needs to be clarified. --Jeroen [1] http://www.debian.org/News/weekly/2004/24/ [2] Technically, this very issue was not a cyclic build-depends at package level, but there was some 'binary in source package' hack involved -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: compilers that self compile
Antonio S. de A. Terceiro [u] wrote on 20/10/2004 18:18: How do people in Debian handle compilers that depend on itself to be compiled? Good question. More precisely: * can a package build-depend on itself? I've saw that gcc, for example, don't (at least explicitily) build-depend on itself. gcc doesn't depend on itself to be built, but it needs _any_ C compiler available to compile an intermediate state of itself, which (basically) then compiles the final stage. That final stage than compiles itself again to check wether the output it the same as from the second compile. * how packages like those go in the repository for the first time? They probably only can go in if there is an alternate way of compiling it, like there is with gcc. I couldn't find references about that on either in Debian Policy Manual or in Debian Developer's Reference. If I missed something, please point me were. I would be interested in the solution, too, but so far I don't know a single compiler which absolutely needs itself to compile. cu, sven
