Alr.Commands.Toolchain: tweak for multiple components and install dir (#822)
* Alr.Commands.Toolchain: tweak for multiple components and install dir
This patch adds support of multiple components and allow
--disable-assistant with all commands so that it is possible to
configure all the toolchain stuff in one command:
$ alr toolchain --select gnat_native gprbuild --disable-assistant
The patch also introduces a --install-dir switch to allow installation
in any directory. This can be useful for people willing to use the Alire
toolchain outside of an Alire workflow. It would be better if the root
dir of the archive (e.g. gprbuild_21.0.0_349f6f95) was skipped so that
all the tools would be available from <INSTALL_DIR>/bin/.
* tests: increase gnat_native version in fixture index and add more tests
* Alr.Commands.Toolchain: print list only when no command is specified
* tests/toolchain/custom_install_dir: fix paths for Windows and second dir
The goal of this big refactoring is to extract the handling of
sub-commands to make it available for other projects.
The SubCommander packages (name open to changes) can be extracted to a
dedicated crate or to AAA.
There is at least one regression which is the support of -X for alr
build.
* Alr.Commands.Toolchain: Fix comparison typo from refactoring
* Alr.Commands|SubCommander: Fix exception raise and handling
* Typo
* Address review comments and minor changes
* Another big refactoring on command line handling
The switches are not parsed several times like before. The global
switches parsing is done once, the command specific switch parsing is
done only on the command arguments.
Handling of -X scenario variable switches is now done with regular
GNAT.Command_Line switch handling.
There is a issue with command arguments that contain spaces, it looks
like they are split in multiple arguments. I don't know why.
* Fix args filtering
The concatenation of arguments and re-splitting with
GNAT.OS_Lib.Argument_String_To_List breaks when arguments have
whitespaces: 'alr' 'show' 'a b c' becomes 'alr 'show' 'a' 'b' 'c'.
* Wrap the GNAT Commnand_Line_Configuration to add required features
This was previously done with a GNAT.Command_Line.Extra package that
exploited the internals of GNAT.Command_Line.
This is more portable because less exposed to changes in the internals
of GNAT.Command_Line.
* Rename SubCommander to CLIC.Subcommander and move it to alire/
* Move Alire.Utils.User_Input and Alire.Utils.TTY to CLIC
Hide alr-deployed releases from external detection (#805)
This is done so when a regular compiler from Alire is put in the path, it won't
be doubly available as a regular release and as an external release, which may
be confusing.
Binary crates, toolchain management and use (#775)
* Implement sha256 and hash use test (#765)
* Implement binary origins and their deployment
* `alr install` for shared installations
Essentially, we have a second location for dependencies at ${ALR_CONFIG}/cache.
In following PRs the releases therein will be available during dependency
resolution, to be reused.
`alr install` for manual crate installation
Installed crates are used by the solver
Autodiscover installed releases
Show differences due to changed install status
Install: implement release removal
* Toolchain configuration assistant
Menu for choosing among multiple options
Show actual compiler versions to the user
Install and remember the user choice
User_Input: Take a possible Ctrl-D into account
* Re-enable "provides" in index and use them in alr
New, more flexible provides type
WIP: going back to provides as list of deps
All but loading of "provides"
Loading of provides
Installed provides are used during solving
They're not yet used for regular dependencies
Display provider in the `alr with` variants
Prevent solving of conflicting dependencies
If two releases provide the same crate, they cannot be simultaneously in a
solution.
solver tweaks for provides + externals
Improvements to solution space by reusing releases
When adding a release to a solution, check whether other dependencies can be
satisfied by this same release. Not a big deal, could be disabled if too costly
in the future.
* Use toolchain in solve/build/environment
Insert explicit dependency on the configured gnat
Do not explicitly insert dependency on toolchain
Instead, we simply coerce when given a generic gnat dependency into the
configured one. This is less intrusive as the user does not see unexpected
dependencies on the compiler in the solution (unless explicitly requested).
Extra info in `alr install` list
Generalized assistant for all tools in toolchain
* Rename install command to toolchain
* Implement "provides" for external detectors
For now this is restricted to a single alternate crate name. By necessity, the
equivalence has to be to the same version, whereas provides for regular
releases are more general as they can rely on precise versions which are known
in advance.
* Tweaks for new GNAT crate names
* Solver: reuse known GNAT on generic gnat= dep
* Integrate external gnats in shared releases
This is logical because these are always available in all configurations. But
the important benefit is that the solver can use them in preference to a remote
native compiler.
* Documentation in doc/, `alr help`
* Fixed circularity, Config.Edit is now untangled
* Tweaks to pass existing tests
* Self-review fixes and clean-up
* New tests for toolchains and related features
* Windows-specific testsuite fixes
* Review fixes
In particular, the avoidance of downloading a compiler for a generic gnat
dependency. This is tested in testsuite/tests/solver/compiler-installed
Fabien Chouteau [Tue, 3 Aug 2021 15:39:38 +0000 (17:39 +0200)]
Alr.Commands.Init: change defaults for init project to release mode (#777)
I first decided to make the default better for developers (to catch as many errors as possible), but they end up in release crates which means that the performance is bad as well as the compatibility between compiler versions.
This patch set the defaults to max performance and compatibility.
This system is clearly not very user friendly, maybe we have too many options here.
Profiles like in Cargo could be better.
Deploy dependencies atomically and related cleanup subcommand (#768)
* Use a temporary to fetch & deploy releases
This is done to avoid an interrupted download (for example with Ctrl-C) to
mistake our deployer, which considers an existing directory as a successfully
deployed dependency.
* Cmd.Clean: implement --temp option
To remove any dangling temporaries
* Improve clean --cache to avoid useless downloads
Fix corner case when pinning to a not available version (#767)
* Less confusing user feedback for existing pin
* Typo in comment
* Fix for corner case in which no solution was found
The solution is impossible, but still an incomplete solution should be
returned. In essence, when the user requested an impossible situation by
applying a pin to a non-existent version for a crate already in the
dependencies, the solver reused the old version assuming it would succeed,
which was not the case if the pin is impossible.
* Better pin info separation
* Extra test case for pinning to unavailable version
Minor testsuite tweak for a change in logging format
* Added new-format pins to alire.toml for self-build
* Allow selective update of pins as for regular deps
* Local pins work with new manifest syntax
* Fixed bug in which version pins were not used
* Make version explicit key in user pin
* Fix bug about confirming empty updates
* Roots: Conflated dep updating into single Sync
We had two confusing Update_Dependencies and Update_And_Deploy_Dependencies
that were in practice doing almost the same. There is now a single
Sync_Dependencies.
* Disable tests that rely on `alr pin`
For now, these cannot work as we are going to remove the ability to edit pins
via `alr with`/`alr pin`. This functionality could be reintroduced at a later
time.
* More tests temporarily disabled
Most of those should be reimplemented in their manual edition alternative
* Disable code for pin edition in command-line
* Changes to allow pins to non-dependencies
This is purely for user comfort and will probably result in dependencies having
to be added at publish time. However, if we manage to restore command-line
pinning, we can remove that pain by adding missing dependencies at that time.
* Tests in tests/pin using new pins
Some tests are not easily portable without support from `alr with --use`. Since
that should be easy to implement later, they are disabled for now and will be
enabled in a subsequent patch.
* Documentation on new pins
* Fix for testcase on Windows using path separators
* Spelling fixes, and exclude lockfiles from check
* New test for various invalid pin entries in manifest
Also the required code changes to pass the test
* Fixes from code self-review
* Fixes suggested during code review
* Fix for missed update when there is no lockfile
We were creating an empty lockfile, which was newer than the manifest, and thus
not triggering the expected automatic update.
* Test to check pins are applied with no prior lockfile
This was a bug detected and corrected in the previous commit
* Fix timestamps compare when mixing G.OS_Lib/A.Dirs
* Update pins for self-build
* Disable self-build, that uses CE2021
It cannot succeed until the patches in this very PR are merged, as it is
attempting to build the old code with the new compiler in the setup-alire
action.
Synchronize alire metadata and git submodules (#720)
* Sync submodules and alire metadata
* Reenable self-build in all platforms
* Feedback about build
* Disable macOS
Somehow apt-get ends being called. To be diagnosed.
* Fix environment settings in manifest
This should fix the problem with the macOS build
* Identified and fixed issue with macOS build
The problem is that the native package in the lockfile was being blindly used.
This is a further hint that lockfiles require work to work better
cross-platform.
* Fix issue with indirect dependencies in test
The self-build test has uncovered an issue already reported, and this commit
also fixes minor differences in output for linked dependencies, depending on
whether they contain alire metadata or not (the same information can be
presented regardless)
Also, disabled version printing on setup-alire, and moved here
Simon Wright [Mon, 10 May 2021 13:36:14 +0000 (14:36 +0100)]
Workround for issue #729 (#731)
Updated rules in 3.10.2 and 6.4.1(6) caused the use of
Constant_Reference, which takes the Container as an aliased parameter,
to trip over its use on a container passed as an un-aliased parameter.
* src/alire/alire-conditional_trees.ads (Root): replace
Constant_Reference by Element.
* src/alire/alire-dependencies-states.adb ("="): likewise.
* src/alire/alire-conditional_trees.adb (To_YAML (1)): likewise.
(Image_One_Line): likewise.
(Iterate): replace Constant_Reference.Element.all by just Element.
* Ensure pinned dirs use portable paths when relative
* Adjustments in testsuite for new relative links
* Recursively add links when linking crates
* Compound relative paths when adding links
* Restore inadvertently removed comment
* Relax too restrictive checks
In the case of linked releases, it doesn't matter if these contain expressions
as we don't write them to disk. As for the spurious warning during loading of
links, we may be transitively loading and the assumption on the current
directory is faulty in that case. The check must be performed elsewhere.
* Buildable with the new design, still unimplemented
Only stub bodies
* New expression loader complete, pending ptypes
* Renamed packages Pseudotypes.* to Expressions.*
* Alire.Expressions.* implementation complete
* All functionality complete, tests missing
* System externals now reuse dynamic loaders
* Fixes found by the testsuite, and output tweaks
There is a functional difference that affects the output for some tests:
before, all enum cases received a value, even if it came from an "others"
clause. This meant that all cases were explicitly listed. Now, the "others" is
stored as is, and the output reproduces the contents of the TOML structure. A
few tests had to be adjusted for this.
* Fixes found testing the current stable index
* Remove obsolete documentation
* Implement and test 'x|y' expressions
* Improve output of `alr show` for system packages
* Fixes found during self-review: comments, dead code
Remove Alire.Requisites and Alire.Boolean_Trees (#701)
* Availability as conditional tree
* Refactor up to Alire.Releases
* It builds for all of Alire.*
* It completely builds
* Testsuite passing, minor cosmetic fixes
There is a minor improvement for trees in which a vector with a single value is
promoted to the single value itself. As vectors are delimited by '(' ')', there
are a few test outputs that required eliminating these former extra
parentheses.
* Dead code removal related to old Ada index
* Case exprs excised from Requisites
This allows more dead code removal and some further internal simplifications.
* Removed Requisites and all related dead code
No longer needed, Requisites were useful in the old index for general
expressions, but not anymore in our case-restricted index. Some quite obscure
portions of Alire code can be thus removed.
Cache lockfiles, remove Root global, and related refactorings (#690)
* Changes up to Alire.Roots
* Finished migrating from Workspace
* Root is stored in Alr.Commands.Command for reuse
This way the global Root is no longer reloaded many times, and modifications
are properly encapsulated via the Alire.Roots.Root type. This removes one of
the outstanding code smells in Alire.
* Speed-ups related to lockfile checks
There were a number of overkill checks that furthermore were expensive, loading
the lockfile many times. This became quite noticeable for large lockfiles (once
there is a decent number of dependencies).
* Minor tweaks to comments
* Tweaks after merging from master
Two big PRs were merged from upstream that created some friction with these
changes, requiring minor tweaks.
* Temporarily disable `alr build` CI check
To allow merging with changes in dependencies, temporarily disable the
aforementioned check.
Fabien Chouteau [Wed, 3 Mar 2021 15:18:34 +0000 (07:18 -0800)]
Start support for crate configuration (#673)
This is the possibility for crates to define configuration variables
that will then generate Ada, C, or GPR files based on the values set by
depending crates.
For embedded projects where compile optimization and static memory usage
are important, it is possible to define sizes of cache buffers or
maximum amount of some resources.
It allows to enable or disable features at compile time, such as debug
logging.
projects / alire.git / log