A workmate floated the idea of using rake as a build system for a non-ruby project. Is it possible to extend rake to compliment other languages where the autoconf toolset would usually be used?
There are examples of this, like buildr, the drop in-replacement for maven (for java) that is built on top of rake. There's also raven for java.
Tools like waf and SCons are Python-based build systems that are developed specifically for broad language support.
You can find how to use Rake as an easy replacement for Makefile in the manual...
I use it almost exlusevely for build that I write myself... If you use Java better choice would be Ant and Maven - they have a lot of code behind them... But, as for me, you have to be a little brainf*ed to program in XML, so I often use Rake for many task, and invoke it from Ant/Maven, like that:
<target name="custom_task">
<exec executable="/usr/bin/env">
<arg value="rake"/>
<arg value="some-task"/>
<arg value="param" />
</exec>
</target>
It may not be super efficient, especially if you have to run anything on the JVM it can't use Ant's, so it is not the best idea... I haven't tried JRuby, maybe it would be worth trying...
But for other task - filehandling, doing something with text files, etc. it works really nice for me :-)
I use it to deploy (Capistrano) on several non-Rails projects. One Java (servlet) and several static HTML sites.
Very handy.
I use it to compile Flex applications. I've written wrappers around the Flex SDK command line tools -- it's easy to do for any tool chain that can be called from the command line.
Related
Consider two software projects, proj_a and proj_b, with the latter depending on the former; and with both using CMake.
When reading about modern CMake, one gets the message that the "appropriate" way to express dependencies is via target dependencies; and one should arrange it so that dependent projects are represented as (imported) targets you can depend on. More specifically, in our example, proj_b will idiomatically have:
find_package(proj_a)
# etc etc.
target_link_library(bar proj_a::foo)
and proj_a will need to have been installed, utilizing the CMake installation-and-export-related commands, someplace where proj_b's CMake invocation will search for proj_a-config.cmake.
I like this approach and encourage others to adapt to it. It offers flexibility in the choice of your own version of proj_a vs the system version; and also allows for non-CMake proj_a's via a Findproj_a.cmake script (which again, can be system-level or part of proj_b).
So far so good, right? However, there are people who want to "take matters into their own hands" in terms of dependencies - and CMake officially condones this, with commands such as ExternalProject and more recently, FetchContent: This allows proj_b's configuration stage to actually download a (built, or in our case source-form) version of proj_a.
The puzzling part to me is that, after proj_a is downloaded, say to an external/proj_a directory, CMake's default behavior will be to
add_subdirectory(external/proj_a)
that is, to use proj_a as a subproject of proj_b and build them together. This, while the idiomatic use above allows the maintainer of proj_a to "do their own thing" in my CMakeFile, and only keep things neat and tidy for others via what I export/install.
My questions:
Why does it make sense to add_subdirectory(), rather than to build, install, and perform the equivalent of find_package() to meet the dependency? Or rather, why should the former, rather than the latter, be the default?
Should I really have to write my project-level CMakeLists.txt to be compatible with being add_subdirectory()'ed?
Note: Just to give some concrete examples of how this use constrains proj_a:
Must use unique option names which can't possibly clash with super-project names. So no more WITH_TESTS, BUILD_STATIC_LIB - it has to be: WITH_PROJ_A_TESTS and BUILD_PROJ_A_STATIC_LIB.
You have to account for the parent project having searched for other dependencies already, and perhaps differently than how you would like to search for them.
Following the discussion in comments, I decided to post a bug report about this:
#22904: Support FetchContent_MakeAvailable performing build+install+find_package rather than add_subdirectory
So maybe this will change and the question becomes moot.
Why does it make sense to add_subdirectory(), rather than to build, install, and perform the equivalent of find_package() to meet the dependency? Or rather, why should the former, rather than the latter, be the default?
FetchContent doesn't just have to be for project() dependencies. It can be used for fetching utility scripts too. I'm guessing it was designed with that kind of consideration in mind. If your utility script is just one file, you can just file(DOWNLOAD) and add_subdirectory() directly, but the utilities could be multiple files, such as is the case with aminaya/project_options. FetchContent() uses a lot of the same machinery as ExternalProject, so it can do a lot of the useful things that ExternalProject does. For example, you can use FetchContent to fetch aminaya/project_options as a remote git repo, or as its archive artifacts- ex. v0.20.0.zip
Should I really have to write my project-level CMakeLists.txt to be compatible with being add_subdirectory()'ed?
It's your choice! The reasoning here can be highly objective, or subjective. It's up to you. Some people just like to put in a lot of effort to support whatever their users might want. Some people have a lot of historical configuration baggage and are still catching up to newer CMake. And as you mentioned at the end of your question post, there are certain adjustments that need to be made to accomodate for cleanly allowing people to add_subdirectory() you as a dependency. One example of a project which chose "no" is glew (see issue #314 for explanation).
Just to give another reference to some related work mentioned in responses to the KitWare/CMake ticket your raised, here's the ticket which tracked work on "FetchContent and find_package() integration".
Is there any way to create executable binaries from Ruby/Rake task?
I have simple FileUtil tool written in ruby and I'd like to package it somehow into script that can be run or OSX, Linux or Windows. Is there any way to do that?
Ruby is an interpreted language and not a compiled one like C or Java. Then answering your question is not so easy.
But there are some tools that permit you to protect your source code (encrypting) and creating some packages that are runnable cross platform (but in this case you should ever resolve any dependency).
This question covers pretty good how you can distribuite your code without (or encrypting) your source code: Can you Distribute a Ruby on Rails Application without Source?
Other useful tools that I have founded in these moments:
- Compiling a rake https://github.com/luislavena/rake-compiler
- Debian (.deb) packaging http://crohr.me/pkgr/
I'm trying to compile a project someone wrote in visual C on my Netbeans+cygwin, and there are a lot of libraries I don't have.
One of the problems is conio.h, and it seems like I can use curses.h.
How do I get curses library?
Use Cygwin, as larsmans suggested.
Does a refactoring (able do conscious language-aware rename classes/variables renaming and replace simple constructions instead of doing dumb string search-and-replace) tool exist which can be used without IDE/editor?
I am particularly interested in Scala, C# and PHP languages.
For Scala there is a refactoring library that can be used standalone: http://scala-refactoring.org/
Not exactly what you are looking for, but Bicycle Repair Man, a Python refactoring tool, ships as an editor-agnostic refactoring library. It's actually used via editor/IDE plugins though.
I've written a little library that uses implicits to add functionality that one only needs when using the REPL in Scala. Ruby has libraries like this - for things like pretty printing, firing up text editors (like the interactive_editor gem which invokes Vim from irb - see this post), debuggers and the like. The library I am trying to write adds some methods to java.lang.Class and java.lang.reflect classes using the 'pimp my library' implicit conversion process to help you go and find documentation (initially, with Google, then later possibly with a JavaDoc/ScalaDoc viewer, and maybe the StackOverflow API eventually!). It's an itch-scratching library: I spend so much time copying and pasting classnames into Google that I figured I may as well automate the process.
It is the sort of functionality that developers will want to add to their system for use only in the REPL - they shouldn't really be adding it to projects (partly because it may not be something that their fellow developers want, but also because if you are doing some exploratory development, it may be with just a Scala REPL that's not being invoked by an IDE or build tool).
In my case, I want to include a few classes and set up some implicits - include a .jar on the CLASSPATH and import it, basically.
In Ruby, this is the sort of thing that you'd add to your .irbrc file. Other REPLs have similar ways of setting options and importing libraries.
Is there a similar file or way of doing this for the Scala REPL?
On the command line, you can use the -i option to load a file while starting the REPL:
scala -cp mystuff.jar -i mydefs.scala
Ofcourse you could wrap this in a shell script or batch file and run that instead of the normal scala command.
(I'm using Scala 2.8.0 RC3).
Not sure if this is what you are looking for, but if you put any jars in your SCALA_HOME\lib directory. Then those jars will be available for import in the REPL (using the import keyword).
EDIT: The most convenient option as of now is by setting the CLASSPATH environment variable. Any jars referenced in the CLASSPATH variable are also available for import in the REPL.
Quick answer probably not what you are looking for, but what about typing
:load path/to/some/scala/script/file.scala
in the console?
:load will read in a scala file and execute it as a script.
Another option is to use sbt set up your dependencies and execute the console command.
The final option I can think of is to set the classpath on the command line manually and point it to the jars / class file folders that you want the jvm to know about.
Let me know if any of this interests you and I can provide more details if needed.