Why is figlet source included in xen? Wouldn''t it make more sense to alter xen/Makefile, to have compile.h built from a .in, and the figlet view of the version info, and have the upstream developers regen the figlet part when the version changes? I''m willing to modify the build system to do this. I''m also fixing several other poor implementation of things. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Why is figlet source included in xen? Wouldn''t it make more sense to alter > xen/Makefile, to have compile.h built from a .in, and the figlet view of the > version info, and have the upstream developers regen the figlet part when the > version changes?Perhaps it should be under xen/tools/figlet rather than xen/figlet, but it is tiny and it is useful to have the banner auto-gen''ed from the version number in the Makefile. There''s no obvious advantage to removing it -- it hardly bloats the repository and it takes negligible time to build. Using autoconf/automake would make sense for a highly portable application that must compile on many platforms with many different environments and compilers. For Xen I think it''ll just complicate things. We only support one arch at the moment -- as others are incorporated they will extend compile.h manually for their own compilation environment if it isn''t GCC. The main thing that autoconf does of course is shield you from environment differences (e.g. sysv vs. bsd) -- but Xen never includes system headers so this is also a non-issue.> I''m willing to modify the build system to do this. I''m also fixing several > other poor implementation of things.We recommend as far as possible that you don''t work on improvements in a vacuum. The earlier you let us know what you''re doing, the earlier you get feedback on what we do and don''t want. -- Keir ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 29 Dec 2004, Keir Fraser wrote:> > Why is figlet source included in xen? Wouldn''t it make more sense to alter > > xen/Makefile, to have compile.h built from a .in, and the figlet view of the > > version info, and have the upstream developers regen the figlet part when the > > version changes? > > Perhaps it should be under xen/tools/figlet rather than xen/figlet, > but it is tiny and it is useful to have the banner auto-gen''ed from > the version number in the Makefile. There''s no obvious advantage to > removing it -- it hardly bloats the repository and it takes negligible > time to build.That wasn''t the point I was trying to make. Who changes the version? Only the upstream developers. When building the dist tarball, the upstream developers should regen a banner.h, so that downstream users don''t need to have figlet around, nor installed.> Using autoconf/automake would make sense for a highly portable > application that must compile on many platforms with many different > environments and compilers. For Xen I think it''ll just complicate > things. We only support one arch at the moment -- as others are > incorporated they will extend compile.h manually for their own > compilation environment if it isn''t GCC. The main thing that autoconf > does of course is shield you from environment differences (e.g. sysv > vs. bsd) -- but Xen never includes system headers so this is also a > non-issue. > > > I''m willing to modify the build system to do this. I''m also fixing several > > other poor implementation of things. > > We recommend as far as possible that you don''t work on improvements in > a vacuum. The earlier you let us know what you''re doing, the earlier > you get feedback on what we do and don''t want.For instance, docs/check_pkgs is rather stupid. It calls which twice, which is unnescessary. It also takes the output of which(``), which is not needed. In addition, documentation has the same uses as figlet. Generally only those doing upstream development need to rebuild the docs. Most users don''t have any need to build docs, so they could be pre-built in the tarball. ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Keir Fraser wrote: > Using autoconf/automake would make sense for a highly portable > application that must compile on many platforms with many different > environments and compilers. For Xen I think it''ll just complicate > things. We only support one arch at the moment -- as others are > incorporated they will extend compile.h manually for their own > compilation environment if it isn''t GCC. The main thing that autoconf > does of course is shield you from environment differences (e.g. sysv > vs. bsd) -- but Xen never includes system headers so this is also a > non-issue. If anyone is thinking of changing the build system, I can highly recommend Jam. It handles stuff like dependency scanning and multi-directory builds much better than Make does, allows more portable build specifications, and unlike other modern Make-replacements it does not need a full language runtime (like Ant or Scons do) to run. Jacob ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel