Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm writing a compiler and there are certain things that I simply can't do without knowing where the user will have my compiler and its libraries installed such as including and referencing libraries that add built-in functionality like std I/O. Since this is my first venture into compilers I feel that it's appropriate to only target Linux distributions for the time being.
I notice that a lot of compilers (and software projects in general) include makefiles or perhaps an install.py file that move parts of the application across the user's file system and will ultimately leave the user with something like a new shell command to run the program, which, (in a compiler such as python's case) knows where the necessary libraries are and where the other necessary files have been placed in order to run the program properly.
How does this work? Is there some sort of guideline to follow when designing these install files?
I think the best guideline I can give you at a high level would be:
Don't do this yourself. Just don't.
Use something like the autotools or any of the dozen or so other build systems out there that handle much of the details involved here for you.
That being said they also add a certain amount of complexity when you are just starting out and that may or may not be worth the effort to start with but they will all pay off in the end assuming you use them appropriately and don't need anything too extensively specialized that they don't provide nicely.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Is make not general enough?
makedepend, autoconf, automake all work to build Makefiles. Is there a flaw in make that causes this type of usage to break down for some languages?
How does ant, Bazel, Maven or other system compile or build a project better than make?
make come from Unix and is generally good for "if you have X you need to do Y to get Z" one file at a time (like invoking the C compiler on a C source). All the autoconf/automake/configure tooling is to customize C programs to the actual platform, and is essentially not overlapping with make.
This did not work well for Java as the compiler was fast for compiling multiple files but the overhead of starting the JVM was much too high for compiling one file at a time. So, a different approach was needed. First plain javac, then ant (which for all practical purposes is a scripting language), and then maven (which isn't because that was a bad idea).
So, the answer is that different tools arose for different needs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been using Phing at work (it was set up when I got there), and thinking of using it for some personal projects. One thing I haven't got my head around yet though is what the big appeal is?
What, if any, are the killer features of Phing or Ant? What are the big reasons people choose to use them instead of (for example) just a collection of bash scripts that execute their build actions? I'm sure I'm missing the obvious, hopefully someone can help me. While I understand that some people may prefer not to use phing/ant, I'm hoping to hear from people who do prefer them about why they prefer them. Just so I can make a more informed decision.
Thanks for any direction or links.
The main feature of Ant is to add frustration to your day, when you know you could achieve something in 30 seconds in a Makefile, but end up fighting with Ant for an hour :)
It was a fresh implementation without requiring a functional shell and all the other standard commands that you expect to be available with a shell. I think that's the real killer feature - you can use it on Windows OS.
Ant XML is far more structured and machine-readable - whereas Makefile+shell is essentially Turing complete and extremely generic. Your IDE has a hope of being able to understand Ant XML, the same can't be said in the general case for Makefiles.
Sadly, the reality after all this time seems to be that the IDEs don't make good use of this potential win. Case in point, opening build.xml in Eclipse just shows you XML.
Which I think just leaves the Windows OS rationale. If there was no Windows OS, probably there would be no Ant either.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
In our company we need a project handler so we decided to write our own.
We use CMake and bazaar and we still don't know if to store the informations of the
projects in XML format or in a database.
We are locked at this point: we would like to use as less languages/tools as possible
but we cannot find a way to interface CMake with XML files or databases.
An idea could be Python but it would be really annoying to use a new language just for an interface. We've seen that there's a Python framework (Waf) but we have already used CMake for all our projects and it would take a lot of time to convert all.
We work with Ubuntu and Windows.
Suggestions ?
thanks in advance
Rather than make your own tool, use an off-the-shelf product like something from the Jira suite, or BuildMaster. Many of these have great integration with most build software and don't require you to write and maintain your own stack just to manage projects.
Focus your developer time on solving your business problems, not on reinventing the wheel. Their time is MUCH more valuable than the cost of using a ready-made solution.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm currently trying to write up some software specs for a large-ish project that I'd like to bid out on oDesk (maybe 3k-6k). I have a classical education in computer science, but minimal work experience and I've never worked in a corporate environment.
I've written up 15 pages of project specs for an API that I want to run on Google App Engine. I'm finding the subtleties difficult with issues such as: where to draw the line on what to specify and what not to; how to break the project up into pieces so that if one part goes wrong, other parts can still be used; where and how to set milestones; and how to screen for a candidate who has the skills to properly implement the specs.
I asked a friend what issues I should watch out for and he said:
Make sure specs do not have contradictory information
Make sure specs are not unnecessarily specific because this will turn off more skilled developers
What other pitfalls and common mistakes should I look out for while drawing up project specs?
While it is important to focus on the functionality of what you want to achieve, also keep in mind the non-functional requirements as well. Think about how you want it to perform, security considerations, etc.
One to add to the list
Make sure the specs are unambiguous. (Can only be interpreted one way...Hopefully)
I think these two links will help:
On Reqs And Specs: http://www.pragmaticmarketing.com/publications/topics/02/0204sj
Painless Functional Specifications - Part 2: What's a Spec?: http://www.joelonsoftware.com/articles/fog0000000035.html
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am a CS student and I have a compiler project this year.
I want to know how to manage my project with my three partners.
I know that the compiler has many level and process, and I want to make use of these features to mange my project.
Thanks for any tips/pointers/resources you can provide for me to start.
You haven't really specified what it is that you are compiling, so it's a little difficult to make specific recommendations.
If you're doing something novel, I wrote a blog post a couple of weeks ago that has some specific things to consider:
http://www.plsadventures.com/2009/09/why-programming-language-design-is-hard.html
If it is a pre-existing language you are compiling, then I would work to generate a decent test corpus, and consider using test-driven development to manage your progress.
As you mentioned, there are some obvious components in most compilers that are relatively discrete. I would consider documenting the interfaces that connect these components. For example, if one person is writing the lexer and another is writing the parser, then ensure that you have a list of tokens written down somewhere. The format for your parse and/or abstract syntax trees should be defined and written down so that anybody working on optimisation or code generation is on the same page.
Above all, tests really help this kind of integration. You should be able to build these components separately and put them together, for the most part.
You should use a DCVS like Git or Mercurial, so each of you can develop individually while it's still easy to merge changes.
Next, you should define test cases to know which features you'll need and how you will know that a feature works.
That should help to figure out different areas of the project which don't overlap too much so each member of the team can work without stepping on each others toes.