Recently I've had to work with big, existing projects to get them to compile. So far, it's been a pain in the butt to download all of the necessary libraries and configure the environment correctly.
If I had a checklist that I could hand to project leads, listing: "here's what I need to run your project," that'd save me time and effort.
Does anyone have any checklists, advice or readings on how to simplify compilation of big projects?
thanks
Use build scripts. Compiling a large project shouldn't be any more difficult than compiling a small project. A single command should be all that is required.
without knowing what language you're targeting, I can't be more specific.
almost all nix source distributions come with a README file which should list the dependencies.
Related
I've purchased CodeKit a while ago, it makes front end projects really easy to setup.
The problem is, I'm in what I call a 'Front-end tool hell'
I've checked out Grunt and Yeoman a while back, and I don't see the point of using these tools if I'm using CodeKit. Am I missing a point?
Short answer: No. You don't miss anything
Longer answer: All of those tools (maybe with the exception of Yeoman) tackle the same thing, but from completely different directions.
Codekit is great to start, because it's like a Swiss army knife of tools, where you actually don't have to do that much work to get it going. Easy to configure and totally easy to use, especially if you don't have any command line experience.
If you want to have things more flexible and you need maybe more than the provided tasks (running a server, creating proxy connections, FTP uploads, having tools included which CodeKit misses); or if you simply need to integrate your builds in continuous integration environments, you will most likely end up with a command line build tool, and also most likely with Grunt. Grunt's biggest strength is in having multiple configurations for different environments. So if you want to have the same code compiled in different ways for different destinations, that works wonderfully with Grunt.
If Grunt can't offer you more than CodeKit, fine, stick with CodeKit!
Grunt has also its limitations, especially in terms of execution time and intermediate file results. That's because in Grunt you take a defined process and configure it. Gulp on the other hand allows you to define the process itself, thus making it even more flexible.
Oh, and concerning Yeoman: If you have a basic setup and like it, write a Yeoman generator and easily scaffold new ones by the push of a button. Or, if you are new to things like, let's say Angular, take a community generator and see what the pros think it's best for such an application. I'm not sure if CodeKit can do "project templates" by now, but that's the idea behind it.
Hope this helped.
I am developing Arduino based system that will enlarge over time. At the moment it has only the humidity and temperature read functionality. But soon a door control, sound recording and gsm web client support will be added. I want all these to be included as libraries and used in the main part. I'm thinking of one ino file that includes all other modules and calls their functions. My question is what is the best and most clean way to do it?
I recommend sticking with libraries and library directories with examples. A library for each component to be interfaced with. This will help in many ways. Such as debugging and reuse.
C:\Users\myself\Google Drive\Arduino\libraries\componentX\componentX.h
C:\Users\myself\Google Drive\Arduino\libraries\componentX\componentX.cpp
C:\Users\myself\Google Drive\Arduino\libraries\componentY\componentY.h
C:\Users\myself\Google Drive\Arduino\libraries\componentY\componentY.cpp
etc...
This keeps it modular and compartmentalized.
Notice I have changed the Arduino's IDE preferences to Google Drive. (Cloud backup and portability)
Then rather than one BIG INO file in your sketch folder
C:\Users\myself\Google Drive\Arduino\somethingBIG\somethingBIG.ino
implement INO files in the
C:\Users\mflaga\Google Drive\Arduino\libraries\component\examples.
directories. This makes it quick to publish the components on GITHUB or Google Drive to share between systems.
Then you can have a sketch file that ties all the components together into your main project.
C:\Users\myself\Google Drive\Arduino\somethingTOPlevel\somethingTOPlevel.ino
You might want to take a look at the Bare Arduino Project.
For my own project Moti, I felt the need to leave the Arduino IDE and use better tools to develop my project. Having to symlink or move every libraries soon felt deeply cumbersome and I looked for another solution. At the same time I was discovering the power of Makefile and stumbled upon Sudar's incredible project: Arduino-Makefile.
I spent time organizing my folders and thought it could be useful for others.
You can think about the Bare Arduino Project as a framework for starting your own project.
I've taken the time to write a lot of documentation. You can learn more about the framework with the README.md and the Installation Instructions.
If you like it or feels like some stuff are missing, I'd love to hear your feedbacks and improvements.
Hope it helps! :)
I am new to cross compiling and willing to get started with cross compiling Qt for beagleboard. Can some one give me specific instructions for this or recently tried tutorial. Please do not assume any knowledge on my part so can not handle instructions like "you may have to edit this to your architecture". I have a few important questions.
how to build Angstrom tool chain and how to prepare it for cross compiling. (I have tried the anstrom web site and never found such random instrutions in my life).
How to cross compile Qt after installing.
The process is a little daunting for the first time developer. I used this blog to give me a start,
http://treyweaver.blogspot.com/2010/10/setting-up-qt-development-environment.html
but like all of the other instructions, sometimes there will be deviations. It took me a while to sort it all out. You are going to have to read and study to to this. It is a worthy thing to do however. As far as Angstom, there are ready made images available. I started with that. You should use Ubuntu to do all of your work. Linux makes it a lot easier.
For open source projects, it's sometimes difficult to find clear build instructions. As a user, I sometimes have to figure out a build process for a piece of software, but then have no obvious way to make that information widely available. What are good ways to release that information?
Someone please make this a community wiki.
The first place I tend to look is in a readme file at the root of the source tree.
Another option, of course, is, if there's a documentation page for the project (and shouldn't there be?) you could have a document there that is specifically about building.
I have inherited a project from a previous developer. All the ASP .NET code behind files are contained within a .dll and the original files are unavailable. Is there any reliable decompiler out there that produces fairly readable code? I've heard mixed responses while browsing other forums - some say there are applications that will decompile .dll files, others say they just produce practically unusable assembly code. Thoughts?
Thanks!
You could try Red Gate's Reflector with the FileDisassembler plugin. Also your heritage seems a little strange. What did the previous developer do with the source code? Didn't he use source control, performed backups? The usability of the source code produced by disassembling a .NET assembly will depend on whether the person that wrote the source code obfuscated it when compiling.
You cannot produce maintainable, properly-designed source code by reverse-engineering a DLL. With clever hacking, you'll be able to alter it to do specific things. Typically, you'll find tutorials on how to bypass licensing/registration checks. (Some of them for stealing my software!)
But your effort will be probably 10x harder than if you had the source code. IMO, you're probably better off treating it as a black box, studying the inputs/outputs, behavior, design documents (if any), etc.. Reverse-engineer REQUIREMENTS from what you see the DLL doing and what the host application needs to do with it. And then get funding/approval for a new project to build a new one. With source code!
Otherwise, your "inheritance" is a liability that you should quickly distance yourself from.
Edit: I missed the part about .net. I don't know much about that, your mileage may be better than a native binary.
--
Chris
I use jetbrains dotpeek
Sometimes you just have to decompile