project-generator / project_generator

Project generators for various embedded tools (IDE). IAR, uVision, Makefile, CoIDE, Eclipse and many more in the roadmap!

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Relative paths in progen

sarahmarshy opened this issue · comments

If I pass a project dict to a progen project, with the paths already set to be relative to the export directory, there are issues.

This function:

def _generate_output_dir(settings, path):
        """ This is a separate function, so that it can be more easily tested """
        relpath = os.path.relpath(settings.root,path)
        count = relpath.count(os.sep) + 1

        return relpath+os.path.sep, count

used in this context:

self.project['export']['output_dir']['rel_path'], self.project['export']['output_dir']['rel_count'] = self._generate_output_dir(self.settings, path)

Where rel_path is used:

 fix_paths(self.project['export'], self.project['export']['output_dir']['rel_path'], list(FILES_EXTENSIONS.keys()) + ['include_paths', 'source_paths'])

Where fix_paths is defined as:

def fix_paths(project_data, rel_path, extensions):
    """ Fix paths for extension list """
    norm_func = lambda path : os.path.normpath(os.path.join(rel_path, path))
    for key in extensions:
        if type(project_data[key]) is dict:
            for k,v in project_data[key].items():
                project_data[key][k] = [norm_func(i) for i in v]
        elif type(project_data[key]) is list:
            project_data[key] = [norm_func(i) for i in project_data[key]]
        else:
            project_data[key] = norm_func(project_data[key])

Is there a specific reason for this complexity? Why can't we just use the built in method relpath to make all files relative to the export directory. There should also be some functionality when paths are already relative to the export directory. We shouldn't append relative prefixes(........) to every path. Should relative paths be disallowed in the yaml/project dicts then?

With relative paths in yaml, the project file is generated correctly by eliminating fix_paths.

This is also dependent on self.settings.root, which is set to be the cwd if one is not provided. If there is no common root, we should think of a better way to handle it than cwd.

If I pass a project dict to a progen project, with the paths already set to be relative to the export directory, there are issues.

Can you write a test case for that to show it fails?

Is there a specific reason for this complexity?

The reason there is that yaml files reference files from a root, and an exported dir might not be in the root, thus tweaking paths is required.

Why can't we just use the built in method relpath to make all files relative to the export directory.

Isn't that what function fix_paths does? Loops through its data and set a correct path? Any suggestions for improvements?

There should also be some functionality when paths are already relative to the export directory.

This is not a common use case, and currently disallowed. how would you provide this functionality?

we should think of a better way to handle it than cwd.

suggestions welcome

The complexity I am talking about is manually appending relative prefixes to all filepaths. That is what fix_paths does. Why not use python's built in relpath?

Can you write a test case for that to show it fails?

This is not a common use case, and currently disallowed. how would you provide this functionality?

If it is disallowed, we know what the test will show, right?

The complexity I am talking about is manually appending relative prefixes to all filepaths. That is what fix_paths does. Why not use python's built in relpath?

Send a patch please to fix it

With relative paths in yaml, the project file is generated correctly by eliminating fix_paths.

relative to what? exported dir?

I'll close this one, has been some time.