Rendre la cible dépendante de la future cible inconnue

Question

Je souhaite que ma cible dépende d'une autre cible dont je ne connais pas le nom ou le chemin au moment où je spécifie ma cible dépendante. Je ne peux pas utiliser Depends à un moment ultérieur lorsque la deuxième cible est connue pour certaines raisons.

Est-il possible de créer une sorte d'espace réservé que je peux définir plus tard? J'imagine quelque chose comme

target1 = <placeholder_of_some_sort> 
target2 = Program(files + [target1]) 

# Set target1 later 
target1 = Object(...) 

Cela ne fonctionne pas, car scons recherche la dépendance de l'espace réservé.

EDIT:

L'exemple montre l'essence du problème que je suis en train de résoudre. En réalité, j'ai un système de construction grand et complexe avec des dizaines de fichiers SConscript appelant d'autres fichiers SConscript d'une manière hiérarchique. je générer une ou plusieurs cibles selon une certaine entrée de l'utilisateur:

for x in user_input: 
    targets.append(env.SConscript(daughter_sconscript)) 

Les cibles générées sont indépendants les uns des autres ... sauf pour un cas limite laid, où, selon une certaine entrée de l'utilisateur, l'un des appelle à l'un des fichiers filles SConscript génère un fichier objet supplémentaire, qui est ensuite utilisé dans un autre appel au même fichier SConscript fille.

L'ordre dans lequel les cibles sont générées dépend de l'entrée utilisateur (types d'utilisateurs scons 1 2 3 vs scons 3 2 1), il est donc pas garanti que l'objet supplémentaire est décrit à SCons, alors que l'appel à la SConscript qui a besoin que cet objet est exécuté. Donc, je veux dire à Scons "Hey, je sais que cette cible va avoir besoin d'un fichier objet, mais il n'a pas encore été décrit".

Je pourrais hardcode un nom pour le fichier objet supplémentaire dans le fichier SConstruct:

extra_object = File("path") 

for x in user_input: 
    targets.append(env.SConscript(daughter_sconscript, exports = {"extras": extra_object})) 

Mais ce encombre mon SConstruct avec des détails. Je veux le garder le plus concentré possible, et laisser le sconscript de fille s'occuper du nom et du chemin.

Merci!

Answer 1

D'abord, je ne voudrais pas utiliser le DefaultEnvironment (Qu'est-ce que vous obtenez lorsque vous utilisez programme et non par exemple env.Program())

env=Environment() 
env.Program('program_name',files + env['SOME_TARGET_NAME']) 

.... later assuming shared env 

env['SOME_TARGETNAME'] = env.SharedObject('fun_source.c') 

Est-ce pour vous le résoudre? Ou avez-vous un autre modèle d'utilisation.

Un flux de travail plus commune serait de créer une bibliothèque (en supposant que ce serait dans un autre répertoire), puis créer un lien qui (par nom) avec le programme

Haut Niveau SConstruct:

env=Environment() 
env.SConscript('program/SConscript', exports='env') 
env.SConscript('other_dir/SConscript', exports='env') 

programme/SConscript:

Import('env') 
env.Program('program_name',files+env['SOME_TARGET_NAME']) 
or 
env.Program('program_name',files,LIBPATH='#/other_dir',LIBS=['otherlib']) 

other_dir/SConscript

Import('env') 
env['SOME_TARGETNAME'] = env.SharedObject('fun_source.c') 
or 
env.StaticLibrary('otherlib',['fun_source.c'])