Recent

Author Topic: Need help understanding why recompiling causes build failures  (Read 4486 times)

CephasAtheos

  • New Member
  • *
  • Posts: 35
Need help understanding why recompiling causes build failures
« on: September 27, 2012, 07:21:17 am »
G'day,

I've run into a bit of a confusing problem, and I can't seem to find out how to solve it.

The issue is that when I do a manual build (Run|Build), the project compiles with the -B flag set.

But when I make a small change to the source (by indenting a line, joining a statement, anything that doesn't cause an error), the automatic rebuild never does a -B rebuild, and so I get a strange error (this is the tail of my message window with the error):
Code: [Select]
Debug: target set to i386 - mach-o
Debug: finished parsing command line parameters
Debug: Trying to open file /Users/Pietje/Sources/lazarus/lcl/units/i386-darwin/finddlgunit.lfm...
Debug: Chosen reader: DFM resource reader
Debug: Reading resource information...
Debug: Resource information read
Debug: Trying to open file /Users/Pietje/Sources/lazarus/lcl/units/i386-darwin/replacedlgunit.lfm...
Debug: Chosen reader: DFM resource reader
Debug: Reading resource information...
Debug: Resource information read
Debug: Trying to opRIFFStalker.lpr(24,1) Error: Error while compiling resources. Compile with -vd for more details. Check for duplicates.
RIFFStalker.lpr(24,1) Fatal: There were 1 errors compiling module, stopping

Now, without touching the code, if I perform a manual build (or a clean-and-build), the same source compiles and links perfectly! (Checking and comparing the outputs, the only difference is the manual build always sets the -B flag, whereas the autobuild never does - and I can't find where to turn that on in the IDE...)

What am I doing wrong, and how can i configure the IDE to automatically perform a clean build when it auto-rebuilds? Alternatively, how can I track down what's causing this to happen in the IDE, since a non-clean build *should* still compile, as only the one single source has changed, which means there must be a "leftover" file somewhere, right?

I can't use the "Always Build" option, because then the error is introduced every time (even for a manual build, or a clean and build) - that just makes things worse!

I'm sure it's something I'm doing wrong, but do you think I can see where? No!  :-[

However, I noticed that earlier in the compile and link process, a space in the project's pathname causes some extremely weird pathname parsing results. But since those same weird results are in the good build, it can't be that.

I've been through the documentation and this site, and I can't find any mention of the duplicate build error, but if I'm missing something, please do let me know!

Cheers,
Pete

UPDATE: Why is it that the error description is so clear in my head, but when it gets to the forum, it reads like a mad woman's pee? Sigh.

Anyway, while trying a couple of the different verbosity options, I found something more interesting that leads me to suspect it's not me, after all.

If I again click 'Run' after the error is generated, the project compiles perfectly!

So, to recap, after making a change and triggering the auto-rebuild, Lazarus generates an error. If the same process is repeated, without any further changes, the error goes away.

I don't even know where to begin looking for this. Can anyone suggest a clue?
Thanks!
« Last Edit: September 27, 2012, 07:36:49 am by CephasAtheos »
Data isn't information. Information isn't knowledge. Knowledge isn't wisdom.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 670
Re: Need help understanding why recompiling causes build failures
« Reply #1 on: September 27, 2012, 01:29:15 pm »
I think this can only be debugged as part of a bug report with a compilable example that demonstrates the problem.

CephasAtheos

  • New Member
  • *
  • Posts: 35
Re: Need help understanding why recompiling causes build failures
« Reply #2 on: September 27, 2012, 04:48:09 pm »
Thanks, Jonas, I guess that's the only thing that will make this a formal issue... Sigh.

I'm a little surprised at how poorly OSX handles so many issues that were solved decades ago. Like spaces in filenames and paths, as one example.

I know that must make life for developers even more difficult!

I wonder, though, how much that has an effect on the debugger? I'm going to try rebuilding the project in a different folder structure, without spaces, and see what effect that has on the problems I'm having. That's about the only constructive thing I can think to do right now.

I noticed in my build log that a parser is chopping up my source path at spaces and feeding that to the debugger, which seems to be putting them back together again, but could this be part of the problem?

I guess I'll find out!

Thanks so much to everyone who's stopped by, and for Jonas, I really appreciate your suggestions, mate.

I feel I should apologise for my less-than-bright tone recently, I'm just at my wits' end with this at the moment. I'm stuck with the Macbook Pro for the foreseeable future (probably 2-5 weeks until I get back on my feet again), so I'm assuming that all these weird and wonderful issues I'm having, have to do with my particular environment. That's what is confounding me, because it's absolutely untouched out-of-the-box (the Mac is only 4 weeks old)! Well, except for my stupid removal (and subsequent reinstallation) of the X11 libraries. (While the Apple newbie website said it's OK to remove X11 since Mac OS X doesn't require it, it's obviously really important for nearly all linux software that runs on a gui, a fact I'm learning every day now!). So there has to be something in my environment that's different to everyone else's, and I have to find out what it is, and fast. Please bear with me!

More shortly. I'm not giving up! :)

UPDATE : 30SEP12
Reinstalling both stable versions of FPC and Lazarus has fixed the rebuild issue. Actually, the Lazarus 1.0RC1 distro had a problem with missing packages, but after pulling the source via svn, and rebuilding, it now works fine and I can build or run (triggering a build) without generating the bizarre errors.
I hope this helps!
-PCP
« Last Edit: September 29, 2012, 04:21:47 pm by CephasAtheos »
Data isn't information. Information isn't knowledge. Knowledge isn't wisdom.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 670
Re: Need help understanding why recompiling causes build failures
« Reply #3 on: September 27, 2012, 04:55:40 pm »
Thanks, Jonas, I guess that's the only thing that will make this a formal issue... Sigh.

I'm a little surprised at how poorly OSX handles so many issues that were solved decades ago. Like spaces in filenames and paths, as one example.
That's not a Mac OS X issue. Mac OS had spaces in folder names, as they were called back then, since its inception. Even the folder containing all system bits was called "System Folder". It's Unix utilities that have a hard time coping with spaces, in particular "make".

Quote
I wonder, though, how much that has an effect on the debugger? I'm going to try rebuilding the project in a different folder structure, without spaces, and see what effect that has on the problems I'm having. That's about the only constructive thing I can think to do right now.
The debugger doesn't care about spaces.

Quote
Well, except for my stupid removal (and subsequent reinstallation) of the X11 libraries. (While the Apple newbie website said it's OK to remove X11 since Mac OS X doesn't require it, it's obviously really important for nearly all linux software that runs on a gui, a fact I'm learning every day now!). So there has to be something in my environment that's different to everyone else's, and I have to find out what it is, and fast. Please bear with me!
I would strongly recommend to install the XQuartz , it's much better than the stock X11 (and also maintained by an Apple engineer, just with a different release schedule): http://xquartz.macosforge.org/

CephasAtheos

  • New Member
  • *
  • Posts: 35
Re: Need help understanding why recompiling causes build failures
« Reply #4 on: September 27, 2012, 05:38:20 pm »
Thanks again for clarifying, mate...

I actually learned about Quartz and installed it instead of the usual X11. Actually, I had by then installed both fink and macports, and both of those broke when I tried to install X11 from their own repositories! Both had different dependency failures, which I reported, but heard nothing back as yet.

I spoke with Apple support, who told me that the only way they could help me get X11 reinstalled was to reinstall OS X Lion!  :o

I'm not joking, that was their considered response after a 40-minute discussion. As Lion is no longer shipped on disk, (it only comes preinstalled), to reinstall Lion meant I would have to reboot in wifi mode, pull down the installable image and install it manually.

Remember, this is so I could get X11 reinstalled. Nothing else. Just X11!!!

That's when I dug a bit deeper, and finally found mention of XQuartz. After the problems with fink and macports, it was a piece 'o cake to install, and after a reboot (which was recommended but not required), it all seemed to be working.

But I'm wondering if there are some tiny incompatibilities that might be causing some of my grief, such as being unable to install qt widgets, or gtk2 as well (I mean - it's technically feasible to do, just not pretty to look at!) So there are quite a few questions I still have to find solid answers for, in terms of why I'm seeing strange problems (apart from the ones I stupidly caused myself!)

It's interesting to confirm that make has space character problems with folders. I last wrote a makefile (by hand back then) in 1982. And it couldn't handle spaces back then, 30 years ago! I know other related tools are out there, but still, it says a lot about priorities when something as basic and fundamental as legal filenames (and pathnames can legally also contain spaces in *nix and windows) still hasn't been fixed. Ah well, it's an opportunity I guess. I seem to be finding many of those lately...

Aaaanyway... Back to regular programming! :)
Data isn't information. Information isn't knowledge. Knowledge isn't wisdom.