I intend to use buildapp for getting executables out of my lisp-code, but I do not understand how I can specify my .asd file for the project, for loading up the code.
I imagined some call like:
buildapp --asdf-file:/path/to/projectasdffile.asd \
--entry-point package:main
But the examples provided by the homepage do not cover a call I recognize as equal, all the example calls look like a whole asdf definition itself. This would be a bit big for a whole project, especially as I already got a whole project definition (using asdf).
Therefore: Is there a way to use buildapp like the imaginary example call provided?
buildapp --load-path /path/to/project --load-system project should do the trick.
Related
I know about using :modules, but what about when systems get nested? Suppose I have the following structure, relative to some unknown user directory:
foo/
-foo.asd
-bar/
--bar.asd
This could arise, for example, when using Git submodules. How shall I configure the (defsystem) call in foo.asd to load bar as a dependency, without modifying a config file outside of foo/ or demanding particular placement for the foo/ tree itself? Feels like it should be simple.
3 Feb. 2020: From #Svante's answer, it sounds like my question is really 'How do I dynamically ensure that foo/ and bar/ both get into the *source-registry*?' The ASDF manual makes me think this should do the trick:
(asdf:initialize-source-registry
'(:source-registry
(:tree "«absolute-path-to-foo»/")
:inherit-configuration))
though I have not seen an example of that usage.
26 Mar. 2020: The technique above seems to work fine, so I'm closing this question. ASDF 3 is excellent.
ASDF doesn't care about relative locations of .asd files. ASDF systems and their dependencies are completely orthogonal to file/directory structure and oblivious to any source version control.
It just looks in several locations for .asd files. Each such file then may contain definitions for systems. It will generally recurse into the configured folders, so any .asd file in a git submodule would usually also be found.
The definitions, e. g. of components, inside of an .asd file then work relatively from the location of that file.
In your example, if you give a :depends-on ("bar") option to the "foo" system, it would just work, no matter where bar.asd resides (as long as it is somewhere where ASDF finds it).
A bit more awareness would be required if you have several versions of a library. This might happen if you work on "foo" and "bar" at the same time, while a stable version of "bar" is also available, e. g. in a quicklisp dist. Then the lookup order comes into play, but usually your “personal” directories have precedence over “system” directories, so again, it would just work. For more control, you might want to look into qlot.
So, in the asdf manual/documentation in section 6.5 of the package-inferred-system extension, the example uses an all.lisp file for determining packages (which I/we will assume will contain all of the function and package information for that respective subdirectoty).
What I want to know is what would be the "proper" way of including all of the function and package declarations in this all.lisp file. Would I do something like including all of the function declarations for that subdirectory in the all.lisp file, and then use the register-system-packages function in the asdf file. Or could I omit the all.lisp file, and let the compiler infer the packages from the files (but would I have to then use the register-system-packages function for every single file I add to this system).
I'm just wondering more about the specifics of using this system and the files and declarations that have to be made when adding a new file to the system.
Sorry for the opacity of the question; I can't seem to grasp the specifics of this system
1- See how it's done in lisp-interface-library/*/all.lisp, using uiop:define-package and its :use-reexport clause.
See for instance pure/all.lisp:
(uiop:define-package :lil/pure/all
(:nicknames :pure)
(:import-from :lil/interface/all)
(:use :closer-common-lisp)
(:mix :fare-utils :uiop :alexandria)
(:use-reexport
:lil/interface/base
:lil/interface/eq
:lil/interface/order
:lil/interface/group
:lil/pure/empty
:lil/pure/collection
:lil/pure/iterator
:lil/pure/map
:lil/pure/set
:lil/pure/alist
:lil/pure/tree
:lil/pure/hash-table
:lil/pure/fmim
:lil/pure/encoded-key-map
:lil/pure/queue
:lil/pure/iterator-implementation
:lil/pure/map-implementation
:lil/pure/set-implementation
:lil/pure/alist-implementation
:lil/pure/tree-implementation
:lil/pure/hash-table-implementation
:lil/pure/fmim-implementation
:lil/pure/encoded-key-map-implementation
:lil/pure/queue-implementation
))
2- These days, I recommend use requiring asdf 3.1 and not using asdf-package-system. For maximal backward incompatibility, use
#-asdf3.1 (error "<my system> requires ASDF 3.1 or later. Please upgrade your ASDF.")
And then in your defsystem, :class :package-inferred-system
3- I do not follow this forum closely. ASDF questions find a quicker answer on the asdf-devel mailing-list.
As I interpret that, you would simply have the package defined in all.lisp depend on the packages defined in the other files of that system. It is then, in a way, an entry point for the dependency graph into that system. I would expect all.lisp to contain high level entry definitions that naturally depend on the other files.
For example, if you build a system that has a (sub-)system for exposing a web interface, the webinterface/all.lisp file/package would contain functions for configuring, starting, and stopping the web server. These functions would depend on the handler definitions in other files/packages which in turn would depend on other files/packages that provide the data or do the meat of request processing.
I'm running lessc as following:
lessc alice/public/local/less/intfarm.less > alice/public/local/css/local/compiled/intfarm.css --source-map=alice/public/local/less/intfarm.map --verbose
the source map is output but it doesn't work. I check the file and at the end I read:
...
,iBAAA;EACA,cAAA;;AA1EZ,IAAI,SA8EA;EACI,gBAAA","file":"../../../../undefined
do I need to set other flags as well?
(shoutout at LESS creators: why not enable this by default and save us hours of work and searching?)
You should not use the > between your source and destiny. In fact your send the output to stdout. The compiler don't know that you are writing the output to intfarm.css and so can not construct the source map link to that file.
Also see: https://github.com/less/less.js/pull/2389
another solution can be using --source-map-map-inline parameter instead of --source-map=... but I think the best solution is the one pointed by Bass Jobsen
I am new to Closure Compiler and when I compile a library I have to work with, a line like this intrigues me:
[jscomp] Compiling 197 file(s) with 41 extern(s)
I'd say some common Web variables like document and window are in, but do I have a way to see this list? java -jar compiler.jar --help didn't give me a hint to such an option. That option should output a list like the following:
document (from gecko_dom.js)
window (from gecko_dom.js)
...
with a total of exactly 41 items. The "(from..." is optional but of course good to have.
By default, closure-compiler uses all of the externs in this folder: https://code.google.com/p/closure-compiler/source/browse/#git%2Fexterns
They are packaged as part of the compiler jar.
Additional externs are available at https://code.google.com/p/closure-compiler/source/browse/#git%2Fcontrib%2Fexterns but must be manually included with the --externs flag.
The definitive list of default externs is listed in the command-line runner source:
https://code.google.com/p/closure-compiler/source/browse/src/com/google/javascript/jscomp/CommandLineRunner.java#868
I'm busy porting my build process from msbuild to cmake, to better be able to deal with the gcc toolchain (which generates much faster code for some of the numeric stuff I'm doing).
Now, I'd like cmake to generate several versions of the output, stuff like one version with sse2, another with x64, and so on. However, cmake seems to work most naturally if you simply have a bunch of flags (say, "sse2_enable", and "platform") and then generate one output based on those platforms.
What's the best way to work with multiple output configurations like this? Intuitively, I'd like to iterate over a large number of flag combinations and rerun the same CMakeLists.txt files for each combination - but of course, you can't express that within the CMakeLists.txt files (AFAIK).
The recommended way to do this is to simply have multiple build directories. From each one you simply call cmake with the required settings.
For example you could do, starting in the base source directory (using Linux shell syntax but the idea is the same):
mkdir build-sse2 && cd build-sse2
cmake .. -DENABLE_SSE2 # or whatever to enable it in your CMakeLists.txt
make
cd ..
mkdir build-x64 && cd build-x64
cmake .. -DENABLE_X64 # or whatever again...
make
This way, each build directory is completely separated from each other.
This allows you to have one directory for Debug, another for Release and another for cross-compiling.
There hasn't been much activity here, so I've come up with a workable solution myself. It's probably not ideal, so if you have a better idea, please do add it!
Now, it's hard to iterate over build configs in cmake because cmake's crucial variables don't live in function scope - so, for instance, that means if you do include_directories(X) the X directory will remain in the include list even after the function exits.
Directories do have scope - and while normally each input directory corresponds to one output directory, you can have multiple output directories.
So, my solution looks like this:
project(FooAllConfigs)
set(FooVar 2)
set(FooAnotherVar b)
add_subdirectory("project_dir" "out-2b")
set(FooVar 5)
set(FooAnotherVar c)
add_subdirectory("project_dir" "out-5c")
set(FooVar 3)
set(FooAnotherVar b)
add_subdirectory("project_dir" "out-3b")
set(FooVar 3)
set(FooAnotherVar c)
add_subdirectory("project_dir" "out-3c")
The normal project dir then contains a CMakeLists.txt file with code to set up the appropriate includes and compiler options given the global variables set in the FooAllConfigs project, and it also determines a build suffix that's appended to all build outputs - any even indirectly included output (e.g. as generated by add_executable) must have a unique name.
This works fine for me.