koobas.hobune.stream
Are Assembly definition files are not build system files?
I spend few days to understand how work assembly definition but one thing is not clear.
In documentation I have fragment:
Assembly definition files are not build system files
Note: The assembly definition files are not assembly build files. They do not support conditional build rules typically found in build systems.
This is also the reason why the assembly definition files do not support setting of preprocessor directives (defines), as those are static at all times.
I do tests.
1st - I marked Assembly Definition file platform only for android. 
And I checked is there assembly in Library-> ScriptAssemlies folder. There is no dll.
2nd - I add in script preprocessor directives. And I opened dll from Library-> ScriptAssemlies folder with IL spy. Preprocessor directives work. 
For me assembly definition support conditional build rules.
My question is what mean that part of documentation? My test are wrong? Could somebody suggest some tests how to check and show this.
This is also the reason why the assembly definition files do not support setting of preprocessor directives (defines), as those are static at all times.
They just wanted to say that assembly definition files do basically just group scripts inside a folder into a seperate assembly. Of course all preprocessor directives work just the same way as if you didn't have those assembly definition files.
In a true build system usually support much more configuration options for each "thing" you build. Classical makefiles which are often used for C / C++ project allow to specify certain rules when a certain object / library has to be recompiled. This is mainly required for languages like C++ where the code is compiled seperately and linked seperately. If something has changed where others may depend on means they have to be recompiled as well.
Assembly definition files do not support any of those fancy build rules. They basically just run the compiler several times with (almost) the same options and just group the corresponding files into seperate assemblies. The only options that are different are the assembly references between those different assemblies. The main point of assembly definition files is to cut down compilation time by letting you group your files in logical chunks. Since each chunk is compiled seperately Unity doesn't need to recompile all scripts whenever you change one of them. Only the assembly that contains the changed file need to be recompiled.
I thought about your answer and I have found this class-: class AssemblyBuilder
Is this class give me posibilities about which you talk? (I think - yes. But I want to be sure)
No, not really ^^. The AssemblyBuilder just gives you direct access to Unity's compilation service. It allows you to just compile certain C# files into an assembly. The C# files and the assembly doesn't need to be part of the project. So it's a simple way to compile a class library without using VisualStudio and actually using the same compiler that Unity uses internally.
Build systems are rarely needed for managed / .NET projects. Unlike C / C++ the compilation time of C# is almost zero. The compilation of large C++ projects can take hours while most C# projects build within seconds. In C# a class library / assembly is much more "standalone" as in C++. If you don't do any breaking changes to an assembly (not method signatures are changed) you usually can just recompile that assembly and just use it. If there is a breaking change you would need to refactor all dependent assemblies anyways which can't be automated (unless you refactor in VisualStudio and have all library projects in the same solution).
Since you usually don't need all those build system features in Unity I'm not sure what you actually search for. Do you miss any particular feature?
I creating free tutorials so when I try to explain topic I do it as well as possible. I search for every connection in documentation, forums, blogs and yt channels to collect community knowledge. I ask because I curious about that, and because I not very familiar with C++ .
Does that mean that I cannot create a script that contains some defines (like UNITY_EDITOR, UNITY_ANDROID, etc.) if I create a assembly definition file for that contains this script?
For what I've tested, I can have a assembly definition for a script and this script uses preprocessor directives. I cannot use them when I pack the scripts into a DLL. Is there something I'm missing?
