Having a bit if fun on stackoverflow

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Jun 27 13:42:12 PDT 2013


On Thu, Jun 27, 2013 at 10:20:59PM +0200, Idan Arye wrote:
> On Thursday, 27 June 2013 at 04:15:27 UTC, H. S. Teoh wrote:
> >Anything else is just the formula for endless frustration,
> >untraceable bugs, and project failure. If your IDE's build function
> >doesn't support full end-to-end reproducible builds, it's worthless
> >and should be thrown out.
> 
> The IDE's build function is not defective - it's just incomplete.

Incomplete == defective. :)


> It does what it does well - the problem is that what it does is not
> enough. Most IDEs I know rely on plugins to do advanced stuff. So if
> you insist on using the IDE's build function, you'll want to get a
> flex plugin for your IDE(hopefully there is one...) and that plugin
> will enhance the IDE's build function to auto-generate the .yy.c file,
> and if it's a good plugin it'll also enhance the IDE's clean function
> to delete that file and/or it's SCM interface to ignore that file.

That's something I never really understood about the Windows / GUI
world. The backend functionality is already all there, yet for some
strange reason the application refuses to have the means to access that
functionality, requiring instead for you to install "plugins". To me, a
"plugin" should *enhance* functionality by adding what wasn't there
before, but in this case, it seems to be more about removing artificial
barriers to reveal what has already been there all along. Same thing
goes with the iPhone emoji apps, and many other such examples.

As a CLI-only person, I find this really hard to grok.


> It's a shame, really - IDEs could do so much more. A few years ago I
> programmed in C#, and I was using Vim. I used MSBuild as my build
> system - it's the build system Visual Studio runs behind the scenes,
> and it's buildfiles are the .csproj files. Those .csproj files are
> basically XML. VS makes them very messy, but after you clean them up
> and understand the format they look pretty much like Ant's build.xml
> files, and you can use them like a proper build system.
> 
> I used those .csproj files to automate the build process, the testing,
> and the deployment. But I could only do it because I broke away from
> Visual Studio! I doubt it would accept those .csproj files after I
> cleaned away all the metadata it put there...
> 
> So people who use VS's build function are actually using a decent
> build system - but they can't utilize it to it's fullest! VS has menus
> that allow you to change some paths and switches, but you can't do
> things like one target that does multiple tasks sequentially. So,
> Visual Studio uses a build system that could automate our .lex file -
> it just forgets to give you access to that functionality...

Yeah, this is something I just don't understand with GUI-centric apps.
It annoys me a lot, actually, that the necessary functionality is
already there, yet there's no way for you to access it without opening
the hood. And too often, the hood is welded shut, esp. when you're
talking about the Windows world. It reinforces my opinion that GUIs are
crippled point-n-grunt caricatures of a *real* UI, which is to use
*language* that can convey what you want in much more expressive ways.


> >Or rather, you throw the IDE out the window, 'cos its build function
> >is defective. :-P
> 
> The IDE is a software - you can't *physically* throw it out the
> window.

It was a proverbial window, not a physical one. :) Well, either that, or
kick it off the GUI window... :-P


> >Then they only have themselves to blame when they face an endless
> >stream of build problems, heisenbugs that appear/disappear depending
> >on what extra commands you type at the command prompt, inability to
> >track down customer reported bugs in old versions, and all sorts of
> >neat and handy things like that.
> 
> If they work alone on the project, it's their problem. If you need to
> join that project - now it's your problem as well.

Which is why I would not touch such projects with a 10-foot pole. The
world is big enough to have more pleasant projects that I work with.


> Good luck with introducing a build system to an existing project and
> making everyone use it...

Heh, yeah. I've been complaining about the nasty mess that is the
Makefile-based build system at my work for a long time, and so far
nobody has listened except for my ex-supervisor (who has since left the
company, sigh). In fact, it's been going downhill. We *used* to support
parallel building. Or at least, some semblance of parallel building, as
long as you make sure certain components are separately built in
single-threaded mode. It saved many many hours of idle waiting. Ever
since the PTBs decided to merge in another major project, though, (which
involved recursively copying all files from said other project on top of
the existing source tree, and then cleaning up the resulting mess),
parallel building has been completely out of the question. Worse yet,
that other project's makefiles were (and still are) so nasty, that you
couldn't simply re-run make after making some changes; you have to make
clean, and then wait 2.5 hours for the miserable thing to build from
scratch.  If you don't make clean, the build will die halfway with
obscure linker errors or errors about missing files, etc..

Gah.

What I would give, to convince people to move to a saner build system...
But old habits die hard, and people dislike change. What can you do.
*shrug*


T

-- 
Let's call it an accidental feature. -- Larry Wall


More information about the Digitalmars-d mailing list