internal: robust pre build

[lijunchen]

if a module doesn't contain any "pre-build" then return early and there will be no lock operation

[peter-jerry-ye-code-review]

From the provided git diff output, I can identify a few potential issues and suggest improvements:

1. Unused Variable Warning in a.mbt:

   let resource : String =
     #|hello,
     #|world
     #|

   This code snippet defines a variable resource but does not use it. This will trigger a warning about an unused toplevel variable. If the variable is intended to have side effects, it should be wrapped in an init function. Otherwise, consider removing it if it's not needed.

   Suggestion:
   If resource is meant to have side effects:

   fn init {
     let resource : String =
       #|hello,
       #|world
       #|
   }

   If not, simply remove the unused variable.

2. Potential Issue in entry.rs with generate_state:

   if let Some(generate_state) = generate_state {
       let generate_result = n2_simple_run_interface(generate_state, moonbuild_opt)?;
       render_generate_result(generate_result, moonbuild_opt.quiet)?;
       Ok(0)
   } else {
       Ok(0)
   }

   This code checks if generate_state is Some and processes it accordingly, but if it's None, it simply returns Ok(0). This might be correct behavior, but it's important to ensure that returning Ok(0) in both cases is intentional and appropriate for the context.

   Suggestion:
   Double-check the logic to ensure that returning Ok(0) in the else case is the desired behavior. If there's a specific action that should be taken when generate_state is None, consider implementing it.

3. Modification in generate.rs to Handle None State:

   pub fn load_moon_generate(
       moonbuild_opt: &MoonbuildOpt,
       module: &ModuleDB,
   ) -> anyhow::Result<Option<State>> {
       // ... [rest of the function]
       if defaults.is_empty() {
           return Ok(None);
       }
       // ... [rest of the function]
   }

   This modification ensures that if defaults is empty, the function returns Ok(None). This is a good practice to handle cases where no default values are provided, but it's crucial to ensure that the calling function can handle a None result appropriately.

   Suggestion:
   Ensure that the calling function correctly handles the Option<State> result, especially the None case, to avoid runtime errors.

These suggestions aim to address potential issues related to unused variables, handling of optional states, and ensuring that the code logic aligns with the intended functionality.