Leif W wrote:
> > "Max T. Woodbury" <max@...>
> > 2005 July 21 Thursday 10:20
> > Observation I:
> > MinGW and MSys form a very good but incomplete development
> > environment. It is better than
> You'd have to specifically detail what you mean by "complete development
> environment". The min in MinGW and the M in MSYS indicate that it's
> intended to be a minimal set of tools, not a full blown development
> environment. Maybe some people want it to be that and nothing more, so
> that they have less to worry about for downloads, installation,
> maintenance and compatibility. That is a valid point and may be hard to
> persuade people otherwise. Personally I don't see a design reason why
> it couldn't be a more complete development environment (some extra
> programs ported, nice package management system, option to fetch docs).
> (Before you throw the rotten tomatos...) The main logistical reason is
> probably that there aren't enough qualified man-hours volunteering to do
> the initial work and also making the long-term committment to
> maintenance. It's hard enough to maintain what there is now.
Yep. Tools that can make maintenance easier would help.
As for 'minimal' - I'm inclined to go for a functional definition -
can I get hold of the original pieces and rebuild it myself. In
that sense, MinGW and MSys are already past the 'minimal' bound.
> > the Cygwin environment largely because it avoids to overhead
> > associated with X11. It is
> Yeah as someone else said, I don't get the connection. Disc space
> overhead or GUI performance overhead? Unless you're referring to using
> an X-specific editor in an emulated X windows environment, I don't get
> it. I've never built X programs in Windows, but thre might be cases
> when that is handy. For example if you have a windows-based X client or
> server that you're building. If I don't really know what to do with
> something, I won't install it, and if nothing breaks and I can do what I
> wanted, then I don't need it.
The point is that X is a mess to deal with and Cygwin has gotten so
big it is impossible to tell what you need and what you don't.
> > correctably worse than Cygwin because it is missing a number of useful
> > elements found in Cygwin like a documentation maintenance suite and
> > the man-pages suite.
> Something like the man page docs require a few extra programs (man,
> groff, some db program which I forget, maybe other things), all of which
> would need to be ported to MinGW or MSYS, while the man pages themselves
> are not modified. So it would largely blow out SourceForge bandwidth to
> transfer non-unique or unmodified data if included, so they wouldn't be.
> The original sources and man pages would be obtained from the upstream
> providers, only the patches from MinGW project. That might be trickier
> to automate the retrieval, but the build process should be unaffected.
Yep. And that's not what is happening. Things are actually getting
duplicated rather than deltad. Figuring out how to do that is one of
the things I think is needed most, but nobody does it now. If it can
be made to work, it could save a fair amount of resources, including
maintainers' time. I'd say more here, but I think it will fit better
Oh, and I took a quick look at MiKTeX a couple hours ago. Like most TeX
suites, it seems to be huge. It looks like a lot of work actually putting
all the pieces together. This is one of those 'tar-baby' things if I'm
> > Observation II:
> > It is not possible to reconstruct the existing MSys environment from
> > the available sources.
> I was wondering about this a bit too. I see a few programs from MSYS
> and MSYS-DTK that are not available for download, either in the FRS or
> the full prdownloads listing. They're available only in the MSYS and
> MSYS-DTK installers. It's probably documented somewhere and I just
> never saw where.
Maybe. Maybe not. It should be obvious where everything came from and
it isn't now. 'mingwPORT' seems to be the right way to go, but I'm
still trying to understand it. There's some stuff in the GNU bootstrap
process as well. A fair amount of this stuff seems to be out of Cygwin.
I mentioned above that this should be deltad not duplicated. At the
moment I'm not doing this very well myself. While the first part of
the process I set up used CVS, some of it still works on copies of .tar
files. The key seems to be 'wget' which I only got to build a day or
two ago and I have not yet learned what I can do with it. I need to
work out the best way to use it. That probably includes a local
cache and automatically applying and creating deltas (like the more
compliant Cygwin packages and mingwPORT seems to do).
> > There are a number of pieces that have become broken over time as well
> > as a number of pieces that have been improved. A good deal of this
> > can be traced to the fact that there is (at least as far as I have
> > seen) no formal build management system. Pieces get added to the
> > system by being built manually and having the files generated
> > added to the list of files to be included in the distribution. The
> > details of the build process have been lost over time and may no
> > longer be reproducible due to changes (usually improvements) to the
> > over all system.
> First, let's distinguish between package management and package build
> systems. I think of these as two separarte tasks, though for
> convenience's sake the RedHat Linux distribution added both
> functionalities to rpm, so the line is blurred if you follow that
> example. In Debian, I don't know if there's a build environment per-se.
> I think it's all packages. You download a source package and maybe an
> optional auxilliary build package with some scripts to automate the
> build using Debian defaults. IMO, some level of package maintenance is
> the precursor to automating the installation process.
I think there are actually three pieces, not just two.
Earnie's working on the package management piece. RedHat uses 'anaconda'.
They only give away the back-end piece. There's apparently some internal
tools that they don't talk about for managing the database anaconda uses.
Some of it is in 'yum'. I know just enough about that to say that it is
a non-trivial problem. It should, if it's done right, mesh with the
other two pieces.
The second piece is the package installation piece. That's one of the
main functions of 'rpm'. INNO also seems to fit into this category.
Again, Earnie seems to have this staked out. I also trust that he
will ask for help if he needs it and that I should stay out of his
The third piece is the build piece. As Christopher mentioned, it's
also part of 'rpm'. It has a dependency problem much like the package
installation dependency problem. That makes it seem to be part of the
installation problem, but the build dependencies can be quite a bit
different from the installation dependencies.
> But I'm "oldschool", like many here, and sometimes I like simple
> tarballs and the option to "just get it and build it myself". While it
> may seem like an inconvenience at first, it also allows a freedom that
> many would not relinquish. This would explain people's opposition.
> Though after I've done the installs a few times, it can get tedious to
> figure out which of all the files is the most recent, so personally if
> there were an auxilliary tool that kept track of all file dependencies
> in a separate, self-contained manner, such that no one is required to
> use it, then I personally would use it, and I think there's be less or
> no resistance from others regarding it's development and existence, so
> long as you're the one to maintain it. Each time a new version of
> something is released, you have to check to make sure there are no new
> dependencies. For example, on the users list, a user had a problem
> building something, and it was related to a new requirement.
Well, I'm looking at the problem at least. There may be more than a few
pieces missing from the MinGW and MSys kit in this regard. Some of the
auto-tools seem to be pointed at this issue. They apparently do a less
than adequate job from the cussing Christopher has directed at them in
the past. I can say with some certainty that there will be a cost
associated with the tool - at the minimum you'll have to run it and it
will almost certainly produce less than perfect results - which you'll
have to fix, either by changing your project structure to make the tool
work better, or by adding what is needed after it's done what it can.
> If you compare this to a full-blown integrated package management system
> like RPM, well, I have a lot of unpleasent memories from my days with
> RPM, due to the dependency problems, bugs in the spec files, configuring
> the code before being thrown into a build, and so on. Being forced to
> use a package management system is not fun.
You got the not fun part right but RPM is not a complete system. One of
the things it assumes, which it shouldn't, is that there's a tarball at
the beginning of the process. It's also a bit NIH about the dependency
problem. At least part of its problem, as I see it, is that the 'spec'
file is designed around the build procedure. It ought to have a more
database like quality to it. In any case a fresh start is indicated.
> Well, as far as generating an installer for MinGW, MSYS, or MSYS-DTK, it
> would be nifty if one could run a command, have it retrieve the MinGW
> files and list what you need to get externally (not necessarily a URL,
> but at the the common name of the application or library and possibly
> the last known URL). The MinGW net installer is in it's initial stages
> and there's probably going to be some flux. Probably building off such
> an existing tool would be the best way to spend energy. It's really a
> moving target right now. That could be interpreted as an opportunity to
> try to make what you want of it. ;-) It currently uses Inno Setup, but
> there was some discussion about the download functions, and NSIS
> (NullSoft Installation System) was thrown out as a possible alternative.
> Earnie pinged the status a few days ago but I saw no pong.
I picked up the INNO kit a while ago but haven't installed it yet. From
what little I've seen of it, its oriented on the installation rather than
the build process. Since I'm working the build end still, I simply have
not needed it.
> > Observation III:
> > Other systems have formal build procedures to avoid this kind of
> > problem. Red Hat uses the RedHat Package Manager (rpm) to avoid this
> > problem. (The published rpm pieces are somewhat less than their
> > complete tool set.) Similarly Cygwin has a number of standards
> > and tools designed to help with this kind of problem. In particular,
> > the auto-tools seem to have been put together to help with this process.
> > However, there is a lot of material in Cygwin that does not use their
> > tools or standards. There are apparently a number of other systems as
> > well including one in Debian (or however you spell it).
> > In other words this is a significant problem and lots of people have
> > worked on it.
> It would be handy to also have some script which allowed for automatic
> building of the build environment. At the very least, I'd like to be
> able to build MinGW, MSYS and MSYS-DTK themselves from sources in an
> automated way, possibly even to wrap in my own all-in-one offline
> installer. I would think that the build part is reasonable, but others
> may not. The installer part is probably left as an exercise for the
I've got it working to the point where I can turn it loose on MSYS or
msysDTK, go to bed and find the logs and other results ready the next
morning. I haven't done MinGW or the mingwPORTs yet, at least partially
because I needed to build 'wget'. I should also be able to build all
the GCC stuff if it's working properly, but I have yet to write that
set of control files.
> > Reaction:
> > I put together a script to allow me to record the details of how to
> > build various packages. I posted various early versions of that
> > script to this and (I think) the MSys mailing lists. As an
> > experimental prototype it was hooky but
> > usable. As
> Hmm, I think SourceForge doesn't archive file attachments to mailing
> lists, and I probably missed that first posting or simply had no idea
> what it was about at that point in my MinGW/MSYS experience.
> > Result:
> > The script builds packages. The build process is controlled by build
> > detail files similar in purpose to the .spec files used by rpm. The
> > detail files are line oriented with each line starting with a tag
> > indicating what is being specified. Among other things, dependencies
> > on the existence of certain files or commands can be specified
> > to prevent building a package that is known to require those files or
> > commands. Groups of detail files are collected into package groups.
> > The entire group can be built or selected packages in the group can be
> > built.
> > Question:
> > Is anybody else interested in this?
> I think it sounds interesting.
OK. It's close to alpha state. I need to put a couple things in the
header before sending it out... From your response I take it that I
can send you a copy when it's ready?
> > Specifically - Earnie - would you use this if I finish cleaning it up
> > and documenting it?
> I'd at least like to get hold of it and see if I could make any sense of
> it without the docs. The docs are good in case I can't figure it out by
> using it. :p
At present it's a single file project - everything, including the docs are
in the one file, but a copy of a set of control files would probably make
the whole thing more understandable...
> > I have a number of really stupid problems - are any of you willing to
> > teach me to solve them?
> I'm probably not experienced enough to answer specific questions.
> Teaching oneself to solve unknown problems is a valuable skill to
> develop. ;-) Anyways, sometimes it's quicker to solve by asking. But
> it's funny to see the "Can I ask a question?" sort of question. The
> wiseguy answers "You just did." Most say "Just ask, don't ask to ask.".
> Well so long as it's a few discreet questions at a time.
Actually I'm quite good at solving unknown problems, but I took a rather
large hit to my self-esteem not too long ago and I'm still trying to get
back on my feet so-to-speak, but that's not quite what I intended by
that question. I know there are people out there who know more about some
things than I do, so I will be asking questions. The problem is that
people will not answer them if I don't produce something useful with
the answers. The implicit question is really 'if I ask stupid questions,
is what I'm doing useful enough that you're likely to answer them in
spite of their stupidity?' but that's way too indirect and verbose.
I do run off at the mouth when I'm anxious...