On 11/6/2013 3:55 AM, Chris Warburton wrote:
BGB cr88...@gmail.com writes:
it is sad, in premise, that hard-coded Visual Studio projects, and raw
Makefiles, are often easier to get to work when things don't go just
right. well, that and one time recently managing to apparently get on
the bad side of some developers for a FOSS GPL project, by going and
building part of it using MSVC (for plugging some functionality into
the app), but in this case, it was the path of least effort (the other
code I was using with it was already being built with MSVC, and I
couldn't get the main project to rebuild from source via the
approved routes anyways, ...).
weirder yet, some of the better development experiences I have had
have been in developing extensions for closed-source commercial
projects (without any ability to see their source-code, or for that
matter, even worthwhile API documentation), which should not be.
This is probably an artifact of using Windows (I assume you're using
Windows, since you mention Windows-related programs). Unfortunately
building GNU-style stuff on Windows is usually an edge case; many *NIX
systems use source-level packages (ports, emerge, etc.) which forces
developers to make their stuff build on *NIX. If a GNU-style project
even works on Windows at all, most people will be grabbing a pre-built
binary (programs as executables, libraries as DLLs bundled with whatever
needs them).
It's probably a cultural thing too; you find GNU-style projects awkward
on your Microsoft OS, I find Microsoft-style projects awkward on my GNU
OS.
primarily Windows, but often getting Linux apps rebuilt on Linux doesn't
go entirely smoothly either, like trying to get VLC Media Player rebuilt
from source on Ubuntu, and having some difficulties mostly due to things
like library version issues.
granted, generally it does work a little better, like at least most of
the time the provided configure scripts wont blow up in ones' face, in
contrast to Windows and Cygwin or similar, where most of the time
things will fail to build (short of some fair amount of manual
intervention and hackery...).
and, a few times just finding it easier to go and port the things over
to building with MSVC (and fixing up any cases where it tries to use
GCC-specific functionality).
granted, it would also require an shift in focus:
rather than an application being simply a user of APIs and resources,
it would instead need to be a provider of an interface for other
components to reuse parts of its functionality and APIs, ideally with
some decoupling such that neither the component nor the application
need to be directly aware of each other.
Sounds a lot like Web applications. I've noticed many projects using
locally-hosted Web pages as their UI; especially with languages like
Haskell where processing HTTP streams and automatically generating
Javascript fits the language's style more closely than wrapping an OOP
UI toolkit like GTK.
can't say, not done much web apps.
I was more thinking though of some of what (limited) experience I have
had with things like driver development.
like, there is some bit of hair in the mix (handling event messages
and/or dealing with COM+), but in some ways, a sort of more subtle
elegance in being able to see ones' code just work in a lot of
various apps without having to mess with anything in those apps to make
it work.
but, in general though, I try to write code to try to minimize
dependencies on uncertain code or functionality.
a few times I have guessed wrong, such as allowing my codec code to
directly depend on my projects' VFS and MM/GC system, but later on
ending up hacking over it a little to make the thing operate as a
self-contained codec driver in this case.
this doesn't necessarily mean shunning use of any functionality outside
of ones' control (in a Not Invented Here sense), but rather it
involves some level of routing such that functionality can enable or
disable itself depending on whether or not the required functionality is
available (for example, a Linux build of a program can't use
Windows-specific APIs, ..., but it sort of misses out if can't use them
when built for Windows simply because they are not also available for a
Linux build).
sort of like codecs on Windows: you don't have to go write a plugin
for every app that uses media (or, worse, hack on their code), nor
does every media player or video-editing program have to be aware of
every possible codec or media container format, they seemingly, just
work, you install the appropriate drivers and it is done.
the GNU-land answer more tends to be we have FFmpeg / libavcodec and
VLC Media Player, then lots of stuff is built by building lots of
things on top of these, which isn't quite the same thing (you need to
deal with one or both to add a new codec, hacking code into and
rebuilding libavcodec, or modifying or plugging into VLC to add
support, ...).
Windows tends to be we have
