I'm compiling a very large code base. If I press Ctrl+C in the middle of make process, do I need to run make clean before continuing the make process. What if the host computer runs out of memory and I had to do hard shut down? I have searched a lot but there are very few suggestions on when someone should do make clean and they are all kinda unclear.
I have searched a lot but there are very few suggestions on when someone should do make clean and they are all kinda unclear.
There cannot be any universal guidance because the effect of make clean depends on the makefile involved. Even the existence of a 'clean' target is merely a convention.
Generally speaking, however, make clean conventionally serves two main purposes:
Getting rid of built files to free space.
Getting rid of built files to overcome makefile shortcomings that prevent make from recognizing when some targets need to be rebuilt.
If your makefile accurately and completely represents all your project's build dependencies then the latter is not relevant, but the larger your project is, the harder it is to be confident about the completeness of your build rules.
If I press Ctrl+C in the middle of make process, do I need to run make clean before continuing the make process. What if the host computer runs out of memory and I had to do hard shut down?
Probably not. The risk is that the build is interrupted in a way that leaves a partially-written or otherwise corrupt new target in place. This is unlikely, and the risk does not scale with the size of the project. But if you need to be absolutely sure of a good build then the safest thing is to clean first and accept the build only if it goes all the way to completion.
Related
I have finished writing a shake-based build system and have reached the deployment stage.
Is there any resource on best practices for deploying Shake-based build systems in intranet scenarios? I'm concerned about things like reproducing a build 5 years from now, whether plain cabal or stack would be a better fit to build the build system itself, how to track the build system dependencies given there's no internet access...
In order to reproduce a build, I'm considering something like generating a Makefile (easy with my approach) prior to tagging a release, and resort to make for building at points that fail to build using the latest shake version. That would avoid storing copies somewhere of all the dependencies used by shake itself over time, but I was wondering if there're better approaches.
For reproducing builds and the build system, the best way to go is a virtual machine image in which you have the OS, along with all things you might otherwise fetch from the web - e.g. Haskell libraries off Hackage. That should give you 100% reproducibility, and is project/language agnostic.
If you want to avoid a complete VM for a Haskell project, the next-best thing is a stack.yaml file, which specifies a given package set, and thus fully ties down every package version, so will stick to an old version of Shake.
Since Shake is much newer than Make, and has a much larger API, it is inevitably going to change more than Make, and will have breaks that mean your old code will not work anymore indefinitely (hopefully rare, hopefully easily fixable). In contrast, Make has been very stable for decades, so a Makefile backup is probably useful to have if it's cheap to create.
Every once in awhile, the solution to an aggravating problem in XCode is to hit Product → Clean, and this seems to clear some cache and problems disappear.
But what is it actually doing? And more importantly, WHEN should I be doing this? It seems to be necessary more often when dealing with Core Data, but I haven't really been tracking it.
As a side question, WHY is this necessary? XCode seems to do a lot of stuff in the background (autosave, autocompile, etc). Why doesn't this also just happen in the background?
It's because there are a lot difference when you are working with a very very big project with a lot of files and objects. Imagine that you need an hour to recompile a entire project, so you will think before do this. But in our world, this is a fast task.
XCode use the make program. So, it compile only what was changed.
I can list same cases you need do this:
Always you will create a App for App Store. This safety thing to do.
Always you use the XCode Snapshot. I have bad time when I restore a project and build the app. XCode used old compiled files and a lot of time was lost to search it.
Maybe when you restore a old code with git. Is the same idea of the Snapshot
When you delete or rename a file in project. It don't delete the compiled file, so the program can work, but if you recompile, will see the errors.
When you see that sometime the build have a strange behavior. Or only to have certain that XCode use only your newer files.
I don't remember exactly but i have seen the build use old #defines. Rebuilding can make you more safe about your program. But don't need do this all time.
I am almost certain that XCode loses track of things and sometimes it doesn't recompile (or link, not sure) everything is needed. I have to resort to clean and build all most often than it should. Maybe it's just me, but I doubt it... XCode is the IDE with most bugs I have worked with
If I ever have a problem that is not showing up as a warning, but makes my app crash on runtime, sometimes I'll build->clean and often it this unkown bug disappears. This happens mostly when I import new images into the project(replacing old ones) or when I make major syntax changes with my code.
F'in 'Clean all Targets', how does it work?
Thanks
When you build for the first time, all of your code is turned into object code. That way when you make a tiny change to one file, you don't have to recompile your whole project, just that one file.
Now sometimes things go funny and stuff doesn't align properly, or dependencies aren't updated and boom crash. The build system is supposed to detect this but every project I've worked on has had this problem at one time or another.
Build clean deletes all the intermediate object code and recompile from scratch.
When you clean your project, you force your entire application to recompile itself. Maybe one of your resources was compiled into your application in a way that required you to recompile everything when changing the resources?
What sort of application are you building - do you use threads? I would make sure they aren't race conditions, because their trademark symptoms are sporadic non-reproducible errors.
We have an automated build server that builds our code nightly, which is useful for us since not everyone on our team can build the entire source tree. Lately, some members of the team are becoming more lax about fixing build errors promptly; sometimes weeks will go by without a successful build. I even overheard one developer say, "the build is already broken, now is a good time to add [some breaking change]." Since I work on the the code the furthest downstream, I am usually working with parts of the tree that are woefully out of sync with the source code repository, which makes it very difficult to test changes before I submit them.
I feel like we're losing most of the benefit of having a nightly build since it is continually broken. Am I way off base here, or should fixing the build be a higher priority?
Fixing the nightly build should be the highest priority. As you said, if they are broken, they have no value. If people wish to check in code that causes breakage, they should do this on a branch and only merge it in when it is tested.
Those devs clearly need to be kicked back into shape.
I'd suggest building at least a few times daily, if not upon checkins. And once you got a successful build cycle going again, have a go (in a joking way) at the person who broke the build - when it happens.
Everyone needs to take ownership of the codebase and take responsibility.
To be honest, it also is about having some pride in your craft. If ultimately people don't give a damn if the build is broken, and they don't after being asked to sort it out, it sounds they'd be better off doing some other job.
The longer you put off fixing it, the longer it will take to fix.
If it's fixed immediately, the things that cause it to be broken should be fresher in everyone's head. Breaking changes could also be piling up making it that much more of a headache to fix later.
It's critical to get it fixed. The longer you put it off, the more things you're going to find later. How can someone tell if their changes have broken the build, if they don't start with a clean build?
Our standard is to have all our unit and functional tests run "green" on a neutral integration box after a commit. Of course, test-driven development is appropriate to our situation, but may not fit yours. If you're not even able to build the project, there are probably bad surprises lurking in previous commits.
If it's so big that the time it takes to build it is standing in the way of getting it fixed, techniques like breaking it up into smaller projects and continuous integration may help.
A friend of mine told me about his team that had the Zucchini of Doom. Anyone breaking the nightly build had to display the ZoD on their desk. This vegetable was in a fairly advanced state of decomposition, which sent out the message quite clearly that a broken build was not something to be tolerated.
If the team isn't motivated enough to keep the nightlies building then this is something that should be enforced/encouraged by the managers.
One of my team mates was held up for mockery by the team leads for preferring to run maven as:
$ mvn clean
$ mvn install
The discussion by the team leaders was about efficiency and speed of work & someone brought up the issue that person X is continuing to split
$ mvn clean install
into 2 separate commands. I know, I know that life is unfair but why would something so innocuous be an impediment to project progress. Would this be an issue for you in your team ?
Dude, you've got serious team-leadership and more generally team-cohesion issues. The bananoseconds that might possibly be "wasted" by running maven twice are nothing, but what this episode suggests about human relationships in the team is big, and sad. Where's management? Are they aware of this? Would they even care? Depending on such issues, my advice might be to print out your resume on the good printer -- hiring is warming-to-heating up again (at least in Silicon Valley), and sticking with a dysfunctional team is not necessarily a necessary evil to keep putting bread on the table...!
Perhaps the real issue is why people on your team are using mockery against each other. That sort of thing is unprofessional and bad for morale in the long run.
I'd say that's a pretty dumb thing to harp on.
Heck, I still prefer to type 3 command rather than doing ./configure && make && make install.
How many time clean task take? If long (I had a project with lot of small files and slow hard drive and clean taks takes more than 30s) you gain that time (including installing) and you can switch to other tasks.
I think that your team leader want to learn you good practices (maybe in a bad example). Assuming mvn install site is much better than mvn install and then mvn site.
It seams that you can replace word compiling with ....
In my opinion if you type less and/or improve your life, that's worth to be done. Read about Kaizen.
Mockery is kid-stuff. Pros know that no two people do things exactly the same.
Like in a marriage, if you can't live with the way she/he puts away socks, and you can't negotiate a middle ground, you have a problem.
Now, I don't know much about Maven, I'll grant you that. But I do know something about code.
Code evolves. This is code.
You write code for clarity, and with at least one eye on maintainability. Unless the difference between separating those commands and not separating them evaluates to a significantly measurable performance impedance, separate them for the sake of maintainability and extensibility.
Well, there are plenty of answers about the politics involved in mocking and receiving that mocking, but I'm actually writing with a technical defense of the question.
Running clean & install in two steps is often helpful. I often do this because clean runs very fast for most maven projects, even large ones. Running clean by itself is a quick way to make sure the project structure is "OK" before proceeding. For this reason, it makes a very convenient gating command either by hand or with a one-liner, e.g., mvn clean && mvn install.
The speed improvement for a project of any size has to be negligible either way.
Actually the 'mocked kid' might be doing a better job. In an ideal world, one would run the 'install' command only if the 'clean' command completed successfully. Something like mvn clean && mvn install would be even better and save precious picoseconds + typing time.
Of course, I have no clue whether mvn actually returns 0 if the command was successful. And doing an install after a clean means that there might be stale files and that the install process doesn't put things where they are supposed to go. But I digress.
Furthermore, you might want to resign and move away from such a workplace as soon as possible. If I were that kid, I'd implement an alias so that mvn clean install wipes your $HOME clean if typed as a single command. Just as a revenge.