Project DEPENDENCIES file
nemerle opened this issue · comments
Following suggestion by @rsaxvc I'm planning on adding a file containing a list of project's DEPENDENCIES. But that rises an interesting question:
Should we try and make the build as self-contained as possible ? And if so, how far should we go with that approach ? ( we can use CMake's external project support and actually download/configure/build boomerang dependencies )
Or maybe we should assume that all people building boomerang are smart enough to figure things out for themselves, and adding a simple DEPENDENCIES file will be enough ?
My personal opinion is that the less time it takes someone to get boomerang to actually build the better, and the project will 'feel' less clunky to the potential new developers :)
Thoughts ? Suggestions ?
The easier it is to start developing the better, a new developer shouldn't need to worry about working out how to configure and make a third party library.
Yes, I really hate it when I'm trying to build some project, and it needs a library, so I have to build that first, but that library needs a tool, so i have to build it before that...... and 4h later I finally can build the freaking thing I wanted to build in the first place ;)
My personal opinion is that the less time it takes someone to get
boomerang to actually build the better, and the project will 'feel' less
clunky to the potential new developers :)
I concur - this is a good goal.
Or maybe we should assume that all people building boomerang are smart
enough to figure things out for themselves, and adding a simple
DEPENDENCIES file will be enough ?
If you're using dependencies commonly available, a DEPENDENCIES file is
certainly enough. But, as a debian user on a dead arch(SPARC), the
current(last) supported release doesn't have QT5 or libboost-1.55. So, I
can build them, but it is a larger barrier to entry versus the original
boomerang codebase, where the only major barrier was age and alignment
faults. I'm certainly not the majority of developers though.Should we try and make the build as self-contained as possible ? And if
so, how far should we go with that approach ? ( we can use CMake's external
project support and actually download/configure/build boomerang
dependencies )
I'm a big fan of breaking things up and modularizing. So, we could have
three parts: a decompiler library with very few dependencies, a
command-line decompiler that didn't use QT, and a nice QT gui, for example.
But, if you're going to pick a big library, QT is nice, and I won't
complain, since my port of boomerang was complete as soon as it compiled.
Is boost only headers? Or are there shared object files to link in as well?
On Thu, Jul 3, 2014 at 4:37 PM, Artur K. notifications@github.com wrote:
Yes, I really hate it when I'm trying to build some project, and it needs
a library, so I have to build that first, but that library needs a tool, so
i have to build it before that...... and 4h later I finally can build the
freaking thing I wanted to build in the first place ;)—
Reply to this email directly or view it on GitHub
#35 (comment).
I'm a big fan of breaking things up and modularizing. So, we could have three parts: a decompiler library with very few dependencies, a command-line decompiler that didn't use QT, and a nice QT gui, for example. But, if you're going to pick a big library, QT is nice, and I won't complain, since my port of boomerang was complete as soon as it compiled.
Well that looks very much like the previous architecture the boomerang had. The original boomerang developers realized that command-line fire-and-forget decompilation was not feasible, especially for larger projects. So, GUI is pretty much a requirement, and since QT has all those time-saving features, it seemed a shame not to use them everywhere :)
As for modularizing things, that is my goal as well, now Loaders are pretty much decoupled from the rest of boomerang, and after I finish #27 I'll be starting on decoupling processor frontends too.
Is boost only headers? Or are there shared object files to link in as well?
Boost in all of it's humongous glory is both actually, some parts of it are header-only, others are shared libraries. I'd prefer we used header-only parts of boost though.
Also re: boost, what do You guys think about using boost::range in boomerang ?
I really like how it made dcc code look:
https://github.com/nemerle/dcc/blob/qt5/src/dataflow.cpp#L306
Just as a side note, One of the original devs covers how he would create boomerang if he was to reimplement it at http://quantumg.blogspot.com.au/2007/04/boomerang-2.html?m=1
I am not to familiar with boost::range not looks useful, I agree with sticking to header only unless there is a big demand.
The other thing we need to decide is having a dependency on llvm, this is a much larger library.
LLVM IR is heavily used in source to source, and source to machine. We should at the least consider it.
See #17.
@nemerle Wouldn't a rudimentary command-line UI aid in debugging?
A panel of switches, bypassing the Wizard, accessible by a button or switch would also work.
Edit: During and after restructuring.
Boomerang actually has such a command-line UI ? Just run ./boomerang -h