I'm using 'lein uberjar' to make a executable jar file of my project.
the jar is created correctly and runs as expected.
I just want to know if it is possible to NOT include my source .clj files in the generated .jar, since I'm planning to distribute it, and I don't want my source files available to the public.
I'm using lein 1.7.1
if not possible with lein, would it work if I just manually removed the .clj files from the jar? I did a test and it worked, by I want to be sure that this is safe to do.
thanks in advance.
Use :omit-source true in lein's project.clj.
Have you tried using the aot compilation step that is provided? See here for an example.
Also, someone blogged something not too long ago about aot compiling their entire project: http://blog.japila.pl/2012/02/aot-compile-all-namespaces-in-a-clojure-project-aot-all-in-project-clj-leiningen/
In that case, too, you might still have to dig in and remove the .clj files, I'm not sure. Maybe this is somewhere to start, though.
Edit 1
I should note that even if you were to use compilation to just distribute the .class files, there are really good tools to decompile those classes in a way that users can read (I've used this in the past when the documentation was so poor I had to look elsewhere to see how it worked).
In those cases, you'd be better off finding a way to implement your own code obfuscator, although I know little/nothing about that topic, here's a start.
Related
Are there some useful ways of triggering complete rebuilds in lein? I'm finding it hard to understand how / when lein reruns/reloads code. Altering files doesn't always seems to result in the changes being applied, and manually requesting recompile for gen-class doesn't always seem to generate files.
Manually deleting files in the target directory doesn't always work, as even if I recompile those files are not always generated so I'll get ClassNotFound errors. How do I have lein properly rebuild everything on each invocation?
edit: most of my confusion was due to not specifying classes created with gen-class in the project.clj file with an :aot directive as suggested in #juan.facorro's comment, e.g.
(defproject
...
:aot [mytestclass.full.packagename.TestClass1 mytestclass.full.packagename.TestClass2 ]
...
)
This sounds like part of a bigger issue: making the clojure development cycle shorter. Once you have your project running happily in the REPL (and this is the first goal) there are several things thats can really drag down the development speed. Changing protocol deffinitions for instance requires you to hunt down and reload every namespace that has instances of that protocol. Stewart Sierra made a great project, gave a presentation and interview about how to set up your project and process so everything that needs reloading is reloaded as quickly as possible.
I use leiningen to manage my clojure project and I want to copy jar file along with some other files into a certain directory as a final part of a build process. Leiningen treats 'resources' as something which should be included into the jar file, and it is unacceptable for me. If I used maven, I could configure it for such task using maven-resource-plugin or fall back to Ant using maven-antrun-plugin, but leiningen is far more convenient tool for clojure projects.
Strangely, I couldn't manage to find anything about similar functionality in leiningen on the internet. This is curious, because one of major clojure applications is web sites, and web sites usually do not include their resources (js, css, etc) into the jar (or do they? That would be weird since slight css tweak will require rather lenghty recompilation). It comes naturally that we have to prepare site environment (copy static resources along with jar bundle into some directory layout), and this task should be done by the build tool.
Is there a plugin to copy files around the filesystem (or something which could substitute it, like running Ant), or I must write one myself? Right now I'm using shell scripts, but it is very inconvenient since I had to run several commands instead of one, and also it is unportable.
did you checkout lein-resource?
in any case. here is a long list of available plugins for lein, maybe you will fine some of them helpful
In my project, I use QWizard and QWizardPages, but at last I found these classes have too much restrict, and I want to modify their source code. But I think it's not a good idea to directly modify qt source, but copy them to my project folder and rename the class names. Is their somebody do the same thing before? I can't compile the files successfully, it seems qMywizard.cpp include the generated moc file of qMywizard.h at the end, and the moc file can't be compile without the QMyWizardPrivate definition. I'm also afraid that many macros can't be recognized when files change location. Can anyone give me some advice?
Qt source is in git. Clone it, make a branch, write your modifications there and compile it with their build system. Also, make sure to understand and follow the license obligations on modifications (especially if you are using the LGPL).
For those who have compiled from source knows how much of a pain it is to run "./configure" only to find that X library or missing, worst yet it spits out a silly line saying a cryptic lib file is missing, which you then have to go to a web browser type in the missing file cross you fingers that Google can find the answer for you...
I find that very repetitive, so my question is:
Is there a way to work out all the required dependencies but without doing "./configure"
Read the README* or INSTALL* files in the source distribution, if there are any, or look for any documentation on the website where you downloaded it from. If the package is well documented, dependencies will usually be listed somewhere.
Given that there's no mention of a specific pkg has been mentioned, I assume this is a generic "how to avoid using configure" question. From a source tarball, no there is no automated way to work the dependencies out. That's what configure is for (you can always read the Makefiles and autoconf files and understand the dependencies manually, but then you'll miss configure very quickly). To avoid it, you need use something other the straight tarball, which has already worked out the dependencies.
For example you can switch to building source rpms (or debs, dependending on your system). Or you can use a system such as Gentoo which is really good at working out the dependencies for you. But all of these require the pkg you're interested in to be available in their format, so they won't work for tarballs that you download from the source provider.
Read configure.ac/configure.in. Look for calls to AC_CHECK_LIB, AC_CHECK_LIBS, AC_SEARCH_LIBS, AM_PATH_* (some old packages that don't use pkg-config put their checks into the AM_* namespace for some reason), PKG_CHECK_MODULES (for pkg-config), AX_* (many autoconf-archive macros are written to check for uncommon dependencies) and any macro call that start with an odd name (i.e., not AC_*, AM_* or AX_*. Try grep '^[^A]'?).
One thing you can do that would be good for the community is to submit a bug report/feature request to the package maintainers. There are quite a few packages whose configure script does not abort on the first missing dependency, but runs to completion and then prints a summary of all the dependencies that are missing. That greatly reduces the tedium you describe. Unfortunately, "quite a few" translates to less than .00001 percent (this is a made up statistic). If you can convince the package maintainers to re-write their configure script to support this behavior, you will contribute to making the world a better place.
Good luck with that!
We are migrating our works repository so I want to do a cull of all the unreferenced files that exist in the source tree before moving it into the nice fresh (empty) repository.
So far I have gone through by hand and found all the unreferenced files that I know about but I want to find out if I have caught them all. One way would be to manually move the project file by file to a new folder and see what sticks when compiling. That will take all week, so I need an automated tool.
What do people suggest?
Clarifications:
1) It is C++.
2) The files are mixed. I am looking for files that have been superseded by others but have left to rot in the repository - for instance file_iter.h is not referenced by any other file in the program but remains in the repository just in case someone wants to compile a version from 1996! Now we are moving to a fresh repository we can safely junk all the files that are no longer used.
3) Lint only finds unused includes - not unused files (I have the 7.5 manual in front of me).
You've tagged this post with c++, so I'm assuming that's the language in question. If that's the only thing that's in the repository then it shouldn't be too hard to grep all files in the repository for each filename to give you a good starting point. If the repository contains other files (metadata, support files, resources, etc) then you're probably going to need to do it manually.
I can't offer an existing tool for it, but I would expect that you can get a lot of this information from you build tools (with some effort, probably). Typically you can at least let the build tool print the commands it would run, without actually running them. (E.g. the -n option of make and bjam does this.) From it you should be able to extract at least the used source files.
With the -MM of g++ you can get all the non-system header files for the given source files. The output is in the form of a make rule, but with some filtering this shouldn't be a problem.
I don't know if this helps; it's just what I would try in your situation.
You can actually do this indirectly with Lint by running a "whole project analysis" (in which all files are analysed together rather than individually).
Configure it to ignore everything but unreferenced variable/enum/function etc warnings and it should give you a reasonable indicator of where the deadwood lies without those issues being obscured by any others in the codebase.
A static source code analysis tool like lint might do the job. They will tell you if a piece of code will never be called.
Have you taken a look at Source-Navigator? It can be used as an IDE but I found to be very good at analyzing source code structure. For example, it can find out where and if a certain method is used in your source code.
I don't know if it's scriptable but it might be a good starting point for you.